EHR Discussions

Overview of Health Information Technology Components

Direct Application to Medical Practices

The Health Information Technology for Economic and Clinical Health (HITECH) Act within the American Recovery and Reinvestment Act of 2009 (ARRA) contains what the Congressional Budget Office estimates will be roughly $36 billion dollars to promote the use of interoperable, certified health information technologies (HIT).  The net cost of this program to the federal government once health care cost savings are factored in is estimated to be approximately $19 billion.  The majority of these funds, approximately $34 billion, are incentives that CMS can use to encourage the use of certified electronic health records (EHRs) by acute and ambulatory care physicians. An additional $2 billion has been made available to the Office of the National Coordinator for Health Information Technology to develop the infrastructure needed to support a marked increase in the use of EHRs and to facilitate their ability to share information.  The goal of this effort is to improve the quality and cost effectiveness of care provided in the United States.

What government programs will provide the incentives to physicians and hospitals?

Incentive funds for meaningful use of EHRs are available through two programs-Medicare and Medicaid.  Each has its own set of eligibility criteria, requirements, and incentive amounts. Eligible professionals must choose to accept payments under either the Medicare or Medicaid programs and cannot receive payments from both.

How does the Medicare program work?

For the Medicare incentives, eligible physicians in ambulatory practices that use a qualified electronic health records are eligible for up to $44K or more per physician over a five year period. These are cash incentives that will be paid directly to care providers or to their employers.  It is by far the most significant direct incentive package for using electronic health records ever offered by the U.S. government.

In principal, the program is straightforward.  CMS will initiate EHR “bonus” payments to physicians who can demonstrate they are “meaningful users” of a certified electronic health record. The bonuses will be offered through 2015 via the following schedule:

Potential Reimbursements Per Each Year

Year of Filing	2011	2012	2013	2014	2015	2016	TOTAL
2011*	$18,000	$12,000	$8,000	$4,000	$2,000	$0	$44,000
2012*	$0	$18,000	$12,000	$8,000	$4,000	$2,000	$44,000
2013*	$0	$0	$15,000	$12,000	$8,000	$4,000	$39,000
2014*	$0	$0	$0	$12,000	$8,000	$4,000	$24,000
2015 or Later	$0	$0	$0	$0	$0	$0	$0

How does the Medicaid program work?

Under the Medicaid incentive plan, eligible physicians can receive up to $63,750 to purchase and use qualified EHRs.  For practices that have not deployed an EHR, the Medicaid program offers up to $21, 250 per physician to help purchase and implement a system (the physician must purchase before 2016 to be eligible). Thereafter, the Medicaid incentives offer up to $8,500 per physician for “meaningful use” of the EHR. The “meaningful use” payments will be available for up to 5 years (with no payments being made after 2021).  Medicaid-eligible professionals must pay at least 15% of the cost to purchase and maintain their EHR technology.  The start date of this program was not defined in the stimulus bill but it is anticipated to begin on or before October 1, 2010.

An eligible physician in the Medicaid incentive program is:

• A non-hospital based physician who has at least 30% patient volume identified as Medicaid insured
• A non-hospital based pediatrician who has at least 20% patient volume in Medicaid insured
• A physician who practices primarily in a FQHC with at least 30% patient volume identified as “needy individuals”[i]

How is “meaningful use” defined?

While this definition is evolving it will include the following basic criteria:

• Use of a certified EHR for patient care documentation and for e-prescribing
• Connectivity to a health information exchange to help coordinate care with other providers
• The ability to submit information on quality measures (e.g. similar to current PQRI and/or Medical Home measures)

The “meaningful use” clause is the government’s requirement to insure that providers are selecting and using EHRs in a manner that help improve quality of care and lower costs.

What is required to be a meaningful user or an EHR and how are EHRs certified?

As per HITECH, meaningful use includes:

1.      Use of a certified EHR including the use of electronic prescribing.

2.      The EHR is “connected” in a manner that provides for the electronic exchange of health information to improve the quality of care, such as promoting care coordination.

3.      Submission of clinical quality measures (and such other measures as selected by the Secretary (of the HHS).

The only current federally recognized certification body for EHRs in CCHIT (Commission for Certification of Health Information Technology).  It has not determined at this writing whether CCHIT will continue as the certification body or if a new entity will be formed to manage this process.

Incentives are available for physicians who are meaningful users starting October 1^st, 2010. If I would like to participate and be eligible for the incentive funds, how long does it take to select the right vendor, implement, and become a meaningful user of an EHR?

1.      The vendor selection process usually take at least six to twelve months as there are multiple vendors to choose from and each has unique features and different levels of ease-of-use.  The first step is to identify what features are most important to your practice.  It has been a challenge for many practices to identify quality vendors.  Many physicians turn to their specialty society (e.g., the American College of Physicians, the American Academy of Family Physicians, etc.) to help them identify suitable vendors.  Current CCHIT certification is also recommended at this time.  The following link identifies the vendors that have the most recent certification: (http://www.cchit.org/choose/ambulatory/08/index.asp).  One a select list of vendors has been made, product demonstrations and actual trial use of the product (e.g., via an on-line practice database) are needed.  Practices must also carefully evaluate the vendor’s training methodologies, support record, and commitment to developing requirements during the evaluation process.  Discussion with other practices using the same system and if possible visits to these clinics are also recommended strongly.

2.      The implementation process typically is delayed for a minimum of 3 months after the contract is signed with the vendor.  Given the dramatic increase in demand for EHRs that is anticipated later this year and next year, vendor waiting lists for implementations may become much longer, even in excess of a year.  The implementation process, once started, may take a week or several months, depending on the size of the practice and the features that are being installed (e.g., practice management software).

3.      Becoming a meaningful user will require the integration of ePrescribing, connections to other healthcare platforms in the community that will allow the practice to share information electronically, and the ability to use the system in a way that captures data needed for clinical reporting.  This process can take several months as it requires that the practices staff undergo training and apply it to the practice’s workflow.

In summary, selecting, implementing and converting a practice to meaningful use of EHRs takes between 12-18 months.  The window of opportunity for attaining the maximum allowed amount under the incentive package requires that a physician become a meaningful user between October 1, 2010 and September 30, 2011.  Following this the incentives payments are significantly lower.

Stephen Lieber, CAE, President and CEO of HIMSS (Health Information and Management Systems Society) stated “The time for Physicians to purchase is now. The idea behind the package is to strongly encourage physicians to buy, then to reward them for doing so. Now is the time for providers and organizations to align themselves with vendors and products that meet the current standards of service and functionality, verify that they are committed to maintaining any future standards as well – and get that in writing – and look at implementing.”

Are there financial benefits available now, even before incentive money becomes available?

Currently through the section 179 tax write off, practices are able to write off up to $250,000 of software and related equipment purchased. For practices that can use this tax benefit, this clause functions as a 35% discount off of your purchase price! For example, if you purchased and installed $50,000 of EMR software and hardware in 2009, you would be able to depreciate, or write off the full $50,000 this year which translates to total cash savings on your purchase of $17,500. It is important to note that the section 179 deduction is re-evaluated annually and may or may not be in effect in future years.

In addition, the Medicare Improvement for Patients and Providers Act (which provides incentives for the use of e-prescribing) offer providers a 2% increase in Medicare reimbursement for e-prescribers in 2009 and 2010, a 1% bonus in 2011 and 2012, and .5% bonus in 2013. As you can see the bonus structure favors providers that act now.

Are there disincentives for not using EHRs?

Beginning in 2015, practices that are not “meaningful users” of EHRs will be subject to the following penalties:

            1% reduction in Medicare fee schedule for 2015

            2% reduction in Medicare fee schedule for 2016

            3% reduction in Medicare fee schedule for 2017



For 2018 if less than 75% of all physicians are meaningful EHR users, then the penalties may be reduced an additional percentage point up to a maximum 5% reduction.

What if I have already purchased an EHR and am a “meaningful user”? Do I qualify?

If you are using an EHR that currently meets the (pending) certification criteria and are doing so in way that meets the meaningful use criteria you will be eligible to receive the incentive payments.

To view the HIMSS summary of the American Recovery and Reinvestment Act of 2009, click here.

For more information on Section 179 Deduction Incentives, click here or contact your CPA.

For more information on CCHIT Certification, click here

To view slides from the Overview of the ARRA 2009 Webinar, click here.  (HIMSS members may view an archived version of the webinar via the HIMSS member login.)

---

[i] “Needy individual” includes patients covered through Medicaid, SCHIP or receiving uncompensated or reduced fee care.

Discussion:

What do you think will be the ARRA of 2009’s greatest impact?

Where are you in the EHR implementation process?

A successful Electronic Health Record (EHR) implementation hinges upon choosing the right system for your practice.  Equally important is how you approach the process of actually implementing the EHR in your practice.   This article will provide recommendations based on knowledge attained from hundreds of successful EHR implementations.

Form a Core Team of Key Office Staff and Decision Makers

Create a team of key office personnel that have the drive and willingness to forge into this new territory.  Typically these individuals are the natural leaders among your staff and people that others will follow as they lead your clinic in this endeavor.  Look for leaders in the various departments and groups within your office – billing, reception, office manager, nurse, physician – all individuals that will champion the cause.   Your core team must also have authorization to make decision regarding how the clinic is going to use the EHR.  They also have more buy in and willingness to make the transition successful if they have a part in the decision making process and agree on the requirements for success.  If you can have a dedicated project manager that works for your clinic and in concert with the EHR’s project manager, you will be ahead of the game.

 Set Expectations with all Staff

Setting the right expectations and tone for this transition is an extremely important part of the success of your implementation.  Your staff must know what their tasks are, expected results and completion within an expected timeframe.  Your team will be excited about this if the Core Team is excited and will be more apt to embrace the training, practice, workflow and new technology.

Work with the Project Manager from the EHR Vendor

Your EHR Project Managers job is to guide you and your clinic through a successful implementation.  This is accomplished through communication, workflow assessments, skill assessments, organizational and project planning and change management.  The Project Manager will work with you to schedule all tasks, assign individuals or teams to complete those tasks, schedule all installations, training, data conversions, go-live support and follow-on training after Go Live.  Your Implementation Project Manager is the guiding force responsible for overseeing the entire implementation process from start to completion.

Decisions, Decisions, Decisions

Through-out the implementation cycle, your core team will have many decisions to make and those decisions are best discussed with your Project Manager.  Do you want to convert your patient information from your former EMR to your new system?  How do you want the daily patient workflow to be handled?  What about billing?  What Clearinghouse will you use?  Does your EHR Vendor offer hardware and installation services?  Do you have an IT professional on staff or one that you contract with to perform IT services for your clinic?  How do you want to handle training – there are many options and you will want to select the combination of blended learning solutions that best suits your clinic and your staff. 

Drive to meet the dates and goals on the project plan

Your Implementation Project Manager will work closely with the lead core team member or dedicated clinic project manager to drive the tasks, goals and deadlines from early planning stages to Go Live and beyond.  It is important to really look at a calendar and take into consideration the timing of the project’s activities.  Is flu season extremely busy for your clinic – that’s probably not a realistic nor wise choice of time to be working on this project.  Depending on your specialty and geographic location, some time frames will be better than others.  Realize that this project takes time to complete and implementing during any slow times of the year will ease the transition on you and your team.

Train, Train, Train and Practice, Practice, Practice

Learning to use your new EHR effectively is one of the most critical pieces to a successful implementation.  You will be seeing patients and have made this investment to help you improve the quality of care – don’t skimp on training and practice.  Go ahead and make that investment in time to train and really learn the system and give your staff the time to train and practice as well.  Becoming comfortable enough in your EHR system to handle an increased patient load while not increasing the time spent to process those patient charts and claims is only going to come through proper training and then practicing until it is second nature.  It really isn’t that daunting of a task as training over a span of time will ensure you and your team are ready to see that first patient with confidence.

Go Live – You Made It!  Invest in Onsite Go Live Training Support

Regardless of what your EHR Vendor tells you, invest in onsite training support during your Go Live week.  You’ve invested the time and money in this new system and in your staff and everyone is trained and prepared…….and then you open your doors and see that first patient, and the next, and the next and it is wise to have a training specialist onsite with you and your staff as they come upon those questions that only happen when you are seeing patients and using your new system.  Proper preparation and training will keep the patients flowing and onsite training support during those first few days on the system when real life questions and situations present themselves. 

Follow-On Training Post Go Live

Your team has settled into a comfortable pace of seeing more patients, the system is running smoothly and you are now wanting to learn more, run reports, build templates, run some rules, learn more about what this powerful new system can do for your practice.  It’s time for some workflow optimization analysis and training typically around 45-60 days after Go Live week.  You and your team will begin to ask more in-depth questions and will be ready to go to the next level.  Work with your Implementation project manager to schedule online training sessions specific to a topic or area that needs attention or perhaps schedule onsite  Advanced Workflow Optimization Consulting where a highly trained and specialized Workflow Consultant spends time in your clinic with your staff assessing workflow and providing recommendations and education to improve the efficiencies of your office. 

You’ve made a significant investment in your practice, in your staff and in your future.   A well planned out and executed implementation provides a solid foundation to your continued success.  Shoring up this foundation with workflow optimization consulting and training is key to ensuring meaningful use of your new EHR system  in your practice.

Introduction

I. Background
In 1991, the Institute of Medicine (IOM) published a report which detailed a consensus vision for the creation of electronic medical records (EMR) in the U.S. (1) The report presented a number of high level objectives to guide EMR development including improving the quality of patient care, strengthening the scientific basis of clinical practice, and helping to control healthcare costs. The IOM predicted that computerization would lead to a radical transformation of the U.S healthcare delivery system if these goals were achieved.

A decade after this report was published, a follow-up report by the National Committee on Vital and Health Statistics (NCVHS) concluded that the predicted transformation had not taken place and provided an analysis of this failure. (2) The report identified the lack of interoperability and data comparability in healthcare information systems as the main reasons why the IOM goals had not been achieved. NCVHS defined interoperability as the ability of one computer system to exchange data with another computer system and described data comparability as the consistent interpretability of data when shared between computer systems.

II. The Importance of Semantic Interoperability

By addressing the need for interoperability and data comparability, semantic interoperability provides for the exchange of “meaning” between systems. It mandates the use of both a messaging standard and the codification of message data with a vocabulary standard so that the receiving computer system can predictably interpret the data being exchanged. (2) The data received in such an exchange are discrete pieces of information that can be used to trigger drug alerts, clinical decision support, or other knowledge tools in the recipient system.

Semantic interoperability is critical in facilitating health care delivery transformation because patient care typically involves a workflow comprised of related and dependent processes that cross institutional and computer system boundaries. (3) Without this level of interoperability, computerization leads to the creation of islands of electronic medical information which can only be accessed by a subset of those healthcare providers involved in the overall care of the patient. (4) Lack of semantic interoperability perpetuates the same problems of redundant data entry, unnecessary duplicate testing, and medical mistakes that are inherent to paper-based medical record systems.

Acknowledging the importance of semantic interoperability, it is critical to understand why semantic interoperability has been so difficult to achieve in healthcare information systems. The following articles in this series review the major barriers to semantic interoperability and explore potential solutions.

· Barrier #1: Lack of a master reference information model

· Barrier #2: Limited collection of codified clinical data

· Barrier #3: Limited use of controlled medical vocabularies

· Barrier #4: Technical challenges to providing data comparability

· Barrier #5 Lack of a messaging standard which supports semantic interoperability

References

1. Institute of Medicine. The Computer-Based Patient Record. An Essential Technology for Healthcare. National Academy Press. 1991.

2. NCVHS. Uniform Data Standards for Patient Medical Record Information. Report to the Secretary. 2000.

3. McDonald T, MD, Raiford RS, BSN, RN, BC, CPHIMS. Vocabulary Services and Their Role in Outcomes Improvements. ehealthrecordnews. 2002 Nov. – Dec. 2002;3(10):15-20.

4. Duke JR, FHIMSS, MA, Crawford J, PhD. Terminology Services. ehealthrecordnews. 2002 Nov. – Dec. 2002;3(10):1 – 14.

One barrier to achieving semantic interoperability between healthcare information systems has been the lack of agreement in the healthcare IT community on the types and descriptions of data elements necessary to accurately capture patient medical record information. Creating a master reference information model which defines these data elements is critical to provide the foundational framework for the collection and exchange of patient data. (1-4) Without such a reference model, individual EMR vendors have historically created their own proprietary information models which are incompatible with other vendors’ models and make of the exchange of patient data difficult or impossible.

A.Significance of the Problem
To illustrate why a master reference information model is important, consider the seemingly simple task of exchanging a patient problem list between two EMR systems.Because no universally accepted standard exists for modeling a patient problem list, vendors frequently come to different conclusions about the categories of data that are used to populate the list. Some vendors restrict content to only include diagnostic data, while others will also include recent symptoms, family history, and other significant historical patient data. In addition, the attributes associated with problem list entries are defined arbitrarily by vendors. For example, an attribute named “date” might be used in one system to designate the date on which a problem list entry was added to the system, while the same attribute in another system might be used to record the date on which the problem started.

B. Possible Solution: Extensions to the HL7 RIM
HL7 (Health Level Seven) is a standards organization that has created a high-level functional model for electronic messaging purposes called the Reference Information Model (RIM). The RIM is necessarily abstract because of HL7’s intent to model the entire healthcare domain. This level of abstraction makes the RIM unsuitable for direct use as an implementation guide for data modeling within specific domains such as electronic medical records. (1) For example, there are no classes in the RIM which describe the exact composition of a patient problem list. However, there are several recent initiatives to create domain-specific information models based on the RIM. (5-7) The most promising of these initiatives are the HL7 CDA (Clinical Document Architecture) and CCD (Continuity of Care Document) projects. The CDA is an ANSI-approved document markup standard that “specifies the structure and semantics” of clinical documents such as progress notes and procedure notes. (7) The CCD is the result of a collaborative effort between ASTM and HL7 which builds upon the CDA standard to define a minimum data set for the exchange of patient health summary information. Because adoption of the CDA and CCD by software vendors frequently requires modification of their systems’ underlying data models, these standards are, in effect, pushing vendors toward a master reference information model based on the HL7 RIM.

Next>> Barrier #2: Limited collection of codified clinical data

References

1. Chute CG, Koo D. Public health, data standards, and vocabulary: crucial infrastructure for reliable public health surveillance. Journal of Public Health Management & Practice. 2002;8(3):11-7.

2. Hammond WE. The Making And Adoption Of Health Data Standards. Health Affairs. 2005 September/October 2005;24(5):1205-13.

3. Coyle J, Mori A, Huff S. Standards for detailed clinical models as the basis for medical data exchange and decision support. International Journal of Medical Informatics. 2003 Mar;69(2-3):157-74.

4. McDonald C. The barriers to electronic medical record systems and how to overcome them. Journal of the American Medical Informatics Association. 1997 May-Jun;4(3):213-21.

5. Bakken S, RN, DNSc, Campbell KE, MD, PhD, Cimino JJ, MD, Huff SM, MD, Hammond WE, PhD. Toward vocabulary domain specifications for health level 7-coded data elements. Journal of the American Medical Informatics Association. 2000;7(4):333-42.

6. Beeler G. HL7 version 3–An object-oriented methodology for collaborative standards development. International Journal of Medical Informatics. 1998;48(1-3):151-61.

7. Dolan, RH. HL7 Clinical Document Architecture, Release 2. Journal of the American Medical Informatics Association. 2006; 13:30-39.

Another significant barrier to semantic interoperability is the limited collection of codified clinical data within most EMR systems. Currently, many systems rely heavily on free text data entry to capture patients’ historical and encounter information. (1,2) Systems which do capture codified data typically encode those data with mappings to their own proprietary data dictionaries. In either the case of free text or proprietary encoding, these data cannot be transmitted between systems and be computer interpretable in the recipient system.

A. Significance of the Problem

To illustrate the significance of this problem, consider again a scenario in which a patient problem list is being exchanged between two EMR systems. System A records an entry of “Diabetes Mellitus Type II” in the problem list as a free text entry and transmits the list to a second system. In System B, the term “DM Type 2” is used as a variable to trigger decision support algorithms and clinical protocols. Although “Diabetes Mellitus Type II” and “DM Type 2” are synonyms, System A has no way to recognize this equivalence and will be unable to use the received data to drive its knowledge tools.

B. Possible Solutions: Structured Data Entry and Natural Language Processing

The most commonly discussed solutions to the codification problem are structured data entry and natural language processing. There are pros and cons to each of these codification methods and the choice of the appropriate method depends on variables such as the documentation style and medical specialty of anticipated end-users.

1. Structured Data Entry

Structured data entry (SDE) solutions typically involve the use of templates or forms which contain pre-coded data entry fields. Because of the relatively rigid control over data entry, ambiguity is removed from the documentation process and critical variables are more likely to be addressed consistently. As a result, SDE has been shown to result in an improvement in the quantity and quality of the data collected during clinical encounters when compared to narrative text dictations. (3)

Unfortunately, studies have also demonstrated some end-user resistance to SDE because of its unfamiliarity to healthcare providers who have been documenting using free form text on paper for years. (4) Another problem is the inability of most SDE applications to handle the non-linear logic that typifies complex clinical scenarios. For example, if a patient presents with a vague symptom such as “abdominal pain”, a clinician will begin the encounter interview with some basic questions regarding variables such as the quality, intensity, and location of the pain. Depending on the responses to these questions, a new series of dependent questions are then asked. Unless a SDE system is capable of addressing this type of branching decision logic, the system will be unable to capture all the clinical variables required to document certain clinical encounters.

These problems with SDE are more pronounced in primary care specialties where the capture of narrative text is considered as much an art form as it is a science and patients typically present with multiple overlapping clinical conditions. SDE, therefore, tends to be a better solution to the codification problem in medical specialties and encounter scenarios where the amount of clinical complexity is relatively limited and the capture of highly nuanced patient narratives is not considered an imperative.

2. Natural Language Processing

As opposed to the capture of codified data during the documentation process, natural language processing (NLP) allows for the extraction of codified encounter data after documentation is complete. The major benefit of this approach is that it allows health care providers to continue documenting using the same free form, narrative documentation style that they are accustomed to. Because of the absence of necessary workflow change, this leads to greater user acceptance when compared to structured data entry. (4) The ability of NLP technologies to extract clinical concepts from free text medical narratives with a relatively high degree of accuracy has been demonstrated in a number of studies. (5,6) A recent evaluation of the MedLEE NLP system, which is used at Columbia–Presbyterian Medical Center, showed that NLP could be used to extract and codify clinical data with mappings to UMLS concepts at a higher degree of accuracy than a panel of human experts. (7)

The application of NLP technologies in EMR systems, however, is currently limited by a number of factors. One is the need for codified data to be available immediately after it is entered so as to drive clinical decision support and other knowledge tools at the point of care. Most of the NLP systems available today perform time intensive, retrospective extraction and codification of clinical documentation. Another limitation is the need for close to 100% accuracy in extracting codified data before the technology can be trusted in a mission critical application like an EMR. No commercially available systems offer a combination of real time concept extraction and codification along with high accuracy levels.

Next>> Barrier #3: Limited use of controlled medical vocabularies

References

1. NCVHS. Uniform Data Standards for Patient Medical Record Information. Report to the Secretary. 2000.

2. Duke JR, FHIMSS, MA, Crawford J, PhD. Terminology Services. ehealthrecordnews. 2002 Nov. – Dec. 2002;3(10):1 – 14.

3. Rosenbloom S, Kiepek W, Belletti J, Adams P, Shuxteau K, et al. Generating complex clinical documents using structured entry and reporting. Medinfo. 2004;11(Pt 1):683-7.

4. Walsh S. The clinician’s perspective on electronic health records and how they can affect patient care. BMJ. 2004 May 15;328(7449):1184-7.

5. Heinze D, Morsch M, Holbrook J. Mining free-text medical records. Proceedings / AMIA. 2001;Annual Symposium.:254-8.

6. Friedman C, Hripcsak G, Shagina L. Representing information in patient reports using natural language processing and the extensible markup language. Journal of the American Medical Informatics Association. 1999 Jan-Feb;6(1):76-87.

7. Friedman C, Shagina L, Lussier Y, Hripcsak G. Automated encoding of clinical documents based on natural language processing. J Am Med Inform Assoc. 2004 Sep-Oct;11(5):392-402.

Codification of clinical data will not solve the semantic interoperability challenge unless the reference vocabularies used are semantically precise and universally recognized as standards. (1,2) Most EMR systems currently only codify data with classification terminologies such as ICD-9 (International Classification of Diseases) and CPT-4 (Current Procedural Terminology). Though this mapping is required for billing purposes, classification systems do not support the capture of clinically specific data at a level precise enough to allow for the comparability of data.

A. Significance of the Problem

To understand the significance of the problem presented by the use of classification systems for codification, consider the use of the diagnostic terms “Staphylococcal Pericarditis” and “Streptococcal Pericarditis” within a patient’s medical record. Though they are clinically distinct terms, they are both mapped to the code “420.99 Pericarditis, Other” in ICD-9. The use of such ambiguous classifiers limits the precision of decision support algorithms within an EMR application and results in a loss of data granularity when clinical data is exchanged between systems.

B. Solution: Standards for Controlled Medical Vocabularies

To address this problem, NCVHS released a report in 2003 which included recommendations for a standard set of medical vocabularies to be used for data codification in EMR applications. (3) The recommendations included Logical Observation Identifier Names and Codes (LOINC) for lab test and other observation encoding, RxNorm for encoding medications, and the Systemized Nomenclature of Medicine (SNOMED-CT) for encoding the remaining patient data. Each of these recommended vocabularies contains clinically precise terminology which could provide data comparability if used to codify patient data being exchanged between systems.

A number of evaluation studies have been performed which tested the adequacy of concept coverage of the NCVHS recommended terminologies within their respective content domains. SNOMED-CT has been shown to provide adequate coverage of diagnostic concepts, (4,5,6) but no formal evaluations of non-diagnostic concept coverage, such as allergies and surgical procedures, have been performed. LOINC has been found to provide adequate coverage of observational data in some studies. (7,8) RxNorm has recently been used to successfully mediate medication and allergy data exchange between the Department of Defense (DoD) and the Department of Veterans Affairs (VA) (9).

Next>> Barrier #4: Technical challenges to providing data comparability

References

1. NCVHS. Uniform Data Standards for Patient Medical Record Information. Report to the Secretary. 2000.

2. Duke JR, FHIMSS, MA, Crawford J, PhD. Terminology Services. ehealthrecordnews. 2002 Nov. – Dec. 2002;3(10):1 – 14.

3. NCVHS. NCVHS Recommendations for PMRI Terminology Standards. 2003.

4. Chute CG, Koo D. Public health, data standards, and vocabulary: crucial infrastructure for reliable public health surveillance. Journal of Public Health Management & Practice. 2002;8(3):11-7.

5. Penz J, Brown S, Carter J, Elkin P, Nguyen V, Sims S, et al. Evaluation of SNOMED coverage of Veterans Health Administration terms. Medinfo. 2004;11(Pt 1):540-4.

6. Wasserman H, Wang J. An applied evaluation of SNOMED CT as a clinical vocabulary for the computerized diagnosis and problem list. AMIA. 2003;Annual Symposium Proceedings/AMIA Symposium.:699-703.

7. Bakken S, Cimino J, Haskell R, Kukafka R, Matsumoto C, Chan G, et al. Evaluation of the clinical LOINC (Logical Observation Identifiers, Names, and Codes) semantic structure as a terminology model for standardized assessment measures. Journal of the American Medical Informatics Association. 2000;7(6):529-38.

8. Choi J, Jenkins M, Cimino J, White T, Bakken S. Toward semantic interoperability in home health care: formally representing OASIS items for integration into a concept-oriented terminology. Journal of the American Medical Informatics Association. 2005;12(4):410-7.

9. Parrish F, Do N, Bouhaddou O, Warnekar P. Implementation of RxNorm as a Terminology Mediation Standard for Exchanging Pharmacy Medication between Federal Agencies. AMIA Annu Symp Proc 2006; 206:1057.

Assuming patient medical data is encoded with standardized medical vocabularies, the technical challenges associated with enabling data comparability present another significant barrier to semantic interoperability. To ensure that data retains their “meaning” when they are interpreted by a recipient system, the EMR must have the ability to recognize synonymy between terms and reconcile differences in the granularity of data. (1,3)

A. Addressing the Need for Synonym Recognition

For basic synonym recognition to be technically possible, the information model of an EMR system must separate clinical concepts from the descriptions of those concepts. (1) This separation allows users of the system to express the same ideas according to their own personal preference and also allows data received from an external system to be recognized as equivalent to local terminology.

For advanced synonym recognition to occur, an EMR system must have the ability to equate pre-coordinated and post-coordinated concepts. (1,2,4) For example, consider a scenario in which System A sends a patient problem list with an entry “Uncompensated Congestive Heart Failure” to System B, but System B does not have this pre-coordinated term defined in its data dictionary. If System B does have two separate concepts “Uncompensated” and “Congestive Heart Failure” defined it its dictionary and makes use of these concepts in decision support tools, it is critical that the system recognize the equivalence of the imported pre-coordinated term and the local post-coordinated expression “Uncompensated” + “Congestive Heart Failure”. Few (if any) of the currently available commercial EMR systems are capable of performing this level of equivalence recognition, but formal mechanisms for doing so have been described and validated. (3,4)

B. Reconciling Differences in the Granularity of Data

Data comparability also requires that a system be capable of recognizing the relationship between clinical concepts which are related but differ in their level of granularity or precision. To understand why this important, consider a scenario in which a family physician consults a cardiologist regarding a patient with periodic chest pain. The cardiologist diagnoses the patient with an uncommon form of angina called “Variant Angina” and sends that information back electronically to the family physician. The family physician’s EMR system has a clinical report defined for finding all patients with “Angina”. For the patient with the more granular diagnosis of “Variant Angina” to be returned in such a report, the system must understand that “Variant Angina” is a subordinate concept of “Angina”. In other words, the system must be able to understand the relationship of similar terms as defined by their relative positions within a concept hierarchy.

Next>> Barrier #5: Lack of a messaging standard which supports semantic interoperability

References

1. Duke JR, FHIMSS, MA, Crawford J, PhD. Terminology Services. ehealthrecordnews. 2002 Nov. – Dec. 2002;3(10):1 – 14.

2. McDonald T, MD, Raiford RS, BSN, RN, BC, CPHIMS. Vocabulary Services and Their Role in Outcomes Improvements. ehealthrecordnews. 2002 Nov. – Dec. 2002;3(10):15-20.

3. Elkin PL, Brown S, Lincoln M, Hogarth M, Rector A. A formal representation for messages containing compositional expressions. International Journal of Medical Informatics Volume 71, Issues 2-3 2003;71(2-3):89-102

4. Dolin R, Spackman K, Markwell D. Selective retrieval of pre- and post-coordinated SNOMED concepts. Proceedings / AMIA. 2002;Annual Symposium.:210-4.

Historically, one of the most significant barriers to semantic interoperability has been the lack of a universal messaging standard robust enough to facilitate the exchange of all patient data in a format that will enable data comparability.

A. Problems with the Existing HL7 V2.x Standard

For almost two decades, HL7 has provided a messaging standard to support the functional interoperability of medical information systems. The standard has been successful in providing for the exchange of laboratory test results and other tabular observational data. However, the flat file format of the current version (V. 2.x) of the standard does not allow for the exchange of complex, relational patient data. (2,3) For example, there is no way to represent a patient’s medication prescription history or family medical history with the existing standard because of the hierarchical nature of these data. In addition, the standard does not allow for the formal definition of a set of data elements to be used for a specific purpose such as the exchange of clinical encounter documents or complete patient summary information. (1)

B. Possible Solutions: ASTM CCR and HL7 CDA/CCD

Recognizing the limitations of the HL7 V2.x standard for exchanging complex data, the ASTM CCR (Continuity of Care Record) was developed as a competing messaging standard which is capable of supporting semantic interoperability of patient health summary data. (5) The CCR uses an XML (Extensible Markup Language) message format, supports relational patient data, and defines a set of data elements necessary to exchange a complete patient medical record between disparate systems. To date, the CCR has been adopted by a wide variety of EMR vendors and has been successfully used to exchange complex patient data between disparate systems.

Also recognizing the limitations of the existing messaging standard, HL7 has developed a new version (V. 3.0) which uses XML to better handle complex patient data. (1) The HL7 CDA (Clinical Document Architecture) was the first test implementation of this evolving standard and is capable of providing a level of semantic interoperability, but its scope was initially limited to the exchange of clinical encounter documents. (2-4) HL7’s CCD project is an extension of the V. 3.0 standard and CDA which allows for the exchange of codified patient health summary data.This standard is the result of a collaborative effort between HL7 and the ASTM CCR team and is widely expected to overtake CCR as the messaging standard of choice for exchanging patient health summary data.

References

1. Bakken S, RN, DNSc, Campbell KE, MD, PhD, Cimino JJ, MD, Huff SM, MD, Hammond WE, PhD. Toward vocabulary domain specifications for health level 7-coded data elements. Journal of the American Medical Informatics Association. 2000;7(4):333-42.

2. Dolin R, Alschuler L, Beebe C, Biron P, Boyer S, Essin D, et al. The HL7 Clinical Document Architecture. Journal of the American Medical Informatics Association. 2001;8(6):552-69.

3. Dolan, RH. HL7 Clinical Document Architecture, Release 2. Journal of the American Medical Informatics Association. 2006; 13:30-39.

4. Muller M, Uckert F, Burkle T, Prokosch H. Cross-institutional data exchange using the clinical document architecture (CDA). International Journal of Medical Informatics. 2005;74(2-4):245-56.

5. Kibbe D, Robert L. Phillips J, M.D., M.S.P.H., Larry A. Green MD. The continuity of care record. American Family Physician. 2004:70(7):1220.

An electronic health record (EHR) that shares a single database with a practice management system is an integral tool that allows physicians to manage their practices more efficiently, reduce overhead and improve the quality of care. This is commonly referred to as an “integrated EHR.”  Cost is one of the most commonly cited reasons why physicians do not implement these systems.  The American Recovery and Reinvestment Act of 2009 contains incentives for using an EHR meaningfully, but in the majority of cases each practice will need to make the initial investment in the EHR they plan to use.  This article will discuss the financial benefits of investing in a fully integrated, single database, EHR/Practice Management system.   It will also describe the benefits of leasing vs. ownership of an integrated system.

Benefits of an Integrated EHR

The financial advantages of owning an EHR have been stated elsewhere and include improved charge capture, elimination of transcription, elimination of paper records, staff reductions, reimbursement through pay-for-performance programs, and reduced malpractice insurance premiums, to name a few.   However, the use of an EHR that shares a single database with a robust practice management application can result in additional savings and enhance revenue.

The following list details some of the advantages of integrated EHR/Practice Management systems:

• Bridge the gap between billing staff and medical staff through process and workflow refinements
  • Readily provide feedback to clinicians that will allow for compliance with correct coding initiatives, even payer specific issues
  • Facilitate better workflow including electronic messaging between billing and clinical staff, reduction in redundant processes, and automation of difficult, necessary and common procedures and follow up requirements
  • Improve charge capture through standardizing billing procedures, automated E&M coding, and more complete charge entry
  • Allow for reporting that pulls clinical and billing data from the same database
• Complete integration of billing, demographics and clinical information
  • Update demographics from the clinical or the practice management application
• Avoid the cost of maintaining an interface between two software products
  • With a non-integrated system, upgrades of one product may lead to one system no longer being able to communicate with the other unless another team works on the interface

Benefits of Leasing

Since the purchase of an integrated EHR/PM system involves the procurement of the equivalent of two software packages, the initial investment is typically somewhat greater than the purchase of an EHR alone.   Two of the most common methods by which practices invest in these systems are by either purchasing or leasing software licenses.   The license purchase is typically several thousand dollars per physician which can cause  concern over the initial capital requirements.  Leasing offers a viable alternative to this so practices should consider its  benefits.    Leasing maximizes the EHR procurement process because it virtually eliminates the upfront capital requirements allowing you to spread out the capital outlay over a period of time that will ensure cash flow remains balanced.  The following outlines additional benefits of leasing.

• Tax treatment – The Internal Revenue Service does not consider certain leases to be purchases but rather tax-deductible overhead expenses. Therefore, medical practices can deduct the lease payments from income, thus reducing the net cost of the lease.
• 100% financing – Since a lease often does not require a down payment, it is equivalent to 100% financing. Physicians can conserve the capital that would have been used for a down payment and reinvest it in the business.
• Immediate write-off of dollars spent – With leasing, payments are treated as expenses on the income statement, so the technology solution does not have to be depreciated over an extended term.
• Flexibility – As physicians’ practices grow and needs change, the lessee may be able to add or upgrade technology at any point during the lease term.
• Asset management – A lease provides the use of the technology solution for specific periods of time at fixed payments. The leasing company assumes and manages the risk of technology ownership. At the end of the lease, if the physician elects to return the technology, the leasing company is responsible for the disposition of the asset.
• Upgraded technology – An EMR can make physicians’ practices more efficient. Technology solutions that could depreciate quickly should be leased to limit a physician’s risk of getting caught with obsolete software. Plus, leases make it easier to upgrade or add technology solutions to meet ever-changing needs.
• Speed – Leasing can allow you to respond quickly to new opportunities with minimal documentation and red tape. Many leasing companies approve applications within a few hours.
• Improved cash forecasting – When physicians lease, they can accurately forecast the cash requirements for the EMR system since they know the amount and number of lease payments required, and with leases, there are no floating fees.
• Flexible end-of-term options – There are typically three flexible options at the end of a term. If the lessee elects to include hardware in the lease, for example, they will have the option of either returning the equipment, purchasing the equipment from the leasing company, or extending the lease for an additional period of time.
• Tax benefits – Leasing companies can pass the tax benefits of ownership on to the physician in the form of lower monthly payments.
• Easier financing than loans – With a lease, physicians can avoid requirements like compensating balances (i.e., deposits banks can use to offset unpaid loans), large down payments, client list reviews, and cash flow projections, making the finance process faster and easier.

Combining the Benefits of Leasing to Acquire the Benefits of an Integrated EHR

Leasing allows physicians to make payments over a period of time and utilize the benefits from the integrated EHR to make those payments.  Most leasing companies will structure the lease with a six month deferral.  This allows a practice to acclimate with the EHR during a period when the practice is not achieving the maximum benefits without making any payments.  This is also especially useful for a new practice which may also be building patient volume during the initial months.

Example:  Three physician practice licenses an integrated EHR/PM system and additional services for $35,000 (including licensing fees, support and training services) and signs a 6 month deferred payment lease with five years of payments.

The average payment factor for the above lease plan would be $819.53 (or $273.17 dollars per physician) per month.  Let’s consider just one of the benefits of an EHR: reduced staffing requirements.  If a practice can reduce one headcount at approximately $43,750 ($35,000 base plus benefits and taxes) this would be a cost savings of $3,645.33 per month.  This one cost saving item alone (not factoring in improved coding, elimination of transcription fees, etc.) would more than offset the monthly lease payment.

In summary, an integrated EHR/PM system has numerous advantages over maintaining an interface between two disparate systems.  The modest increase in the cost of making this purchase is an excellent investment.  Leasing eliminates the need to make a large upfront investment in software and services and should be considered when physician practices are evaluating the cost benefits of purchasing EHR systems.

About Author:

Ted Pakes, CPA

Chief Financial Officer

e-MDs, Inc.

A number of EHR (Electronic Health Record) products feature tools that automate the process of determining the E&M (evaluation and management) code for an office visit. When these tools are properly designed and used appropriately, they result in very accurate coding supported by thorough documentation. This can result in very significant and completely justified increases in revenue, not uncommonly reaching tens of thousands of dollars. This has attracted the interest of auditors, however, including the Office of the Inspector General (the body that performs audits for CMS). There is no certification or formal evaluation process for EHR E&M coding tools. Regardless of what code is suggested by an EHR, the clinician is ultimately responsible for the code submitted for reimbursement.

Physicians who are using automated E&M coding tools should follow these three steps to ensure the codes they submit are accurate:

1. Challenge your vendor to show you how the coding tools comply with published E&M coding guidelines. Most auditors use the 1995 and 1997 Documentation Guidelines for Evaluation and Management Services (these can be downloaded from the CMS website: http://www.cms.hhs.gov/MLNEDWebGuide/25_EMDOC.asp ). The vendor should be able to tell you exactly how the tools capture E&M related information from each section of the note, including the HPI, Past Medical History, Family History, Social History, Review of Systems, Physical Examination, Assessment and Plan. They should also be able to show you how medical complexity and the overall score is determined from this information. The demonstration should also show how time can be used to determine the E&M code in place of documentation when appropriate.

2. Maintain awareness of coding guidelines, i.e., do not become overly reliant on the suggested E&M code. As described below, there are certain patterns that have emerged from EHR usage that have attracted the interest of auditors. These are all readily avoided if the clinician has some very basic understanding of the coding guidelines that can be used to reaffirm or refute the accuracy of the suggested code. It is of obvious importance that the physician be allowed to override the suggested code when necessary. This gives physicians some flexibility and also accommodates different data input options such as typing/voice recognition which are often not recognized as structured data and therefore are hard to map to E&M coding data requirements.

3. Be aware of EHR specific documentation tendencies related to E&M coding that need to be avoided. Some of the more common examples are provided below:

a. The Use of Default Text. EHR vendors assume when they design their applications that all the information that is included in a note has been reviewed by the clinician and is medically necessary based on the level of complexity of the encounter. In order to improve efficiency, EHRs often support the use of templates, macros, and information from a prior visit note that contains information that may or may not be accurate. Given the time pressures associated with the practice of medicine and the ease of use of default information, there is the potential for inaccurate information to be accepted in the form of encounter defaults. While this does seem like it should be a minor or exceptional issue, numerous examples of unreviewed defaults that were accepted as legitimate information have been identified by auditors. One of the more common areas where this type of behavior may occur is the review of systems (ROS). Clinicians need to carefully review the ROS to make sure that any incorrect defaults are modified, and in particular to make sure it is consistent with the HPI. For example, seeing “denies chest pain” in the ROS in a patient with a detailed description of chest pain in the HPI can lead to a negative audit. It may also be worth noting that the physician is not required to actually obtain the PFSH and/or ROS directly from the patient, as the patient or another staff member can document this information but then it must be reviewed by the clinician.

b. The Use of Default Settings. The visit type (e.g., new patient, established patient, consultation, etc.) can often be used to determine which sections of a note are populated with data automatically (e.g., Family History, Social History, etc). A not uncommon pattern is for the clinician to set the defaults to include the Family and Social history for all established visits. In general this is to be avoided. For example if the patient is seen fairly frequently there may not be any medical justification to include the social or family history with each visit. If the use of these sections increase the coding level, auditors are likely to challenge this as a type of “over-coding.” To avoid this relatively common pitfall, consciously determine whether or not the documented information being used to determine the E&M code was medically necessary to include in the document, based on the complexity of the presenting problems. Besides the family and social history, a full ROS (10 or more systems) or a comprehensive physical examination brought in through a template or macro may not be considered medically necessary in some settings.

c. The Use of Additional Diagnoses to Increase the Level of Complexity. One of the three components used to determine the level of complexity of the visit is the “number of diagnoses considered.” However, diagnoses that are used to determine the level of complexity must meet the following criteria:

i. Code to the greatest level of specificity only: Choose only the most specific code for any given presenting problem. For example, in a patient with a firm diagnosis of cluster headache additional symptomatic diagnoses such as “headache” should not, in general, be listed as an additional diagnosis. EHR E&M coding tools will not have the level of sophistication to recognize this as a potential issue.

ii. Use only diagnoses that are relevant to the current visit: EHRs may provide the ability to easily add diagnoses (e.g., from the problem list or previously used diagnoses) to the assessment. If the condition is not relevant to the current encounter it should not be used to calculate the level of complexity of the visit.

d. Documentation Supportive of Complexity. The majority of auditors are not physicians and in some setting may have difficulty inferring complexity from the available documentation. For this reason it is advisable to add to your documentation such things as the differential diagnosis, risk associated with the natural history of the disease, and the risks associated with any proposed interventions. EHRs handle the ability to generate, store and display text of this nature in a number of different ways. However, it is advisable to avoid generating simple bulleted lists of diagnoses and treatments that are not supported by additional documentation in particular when the level of complexity is moderate or high.

In summary, the combination of a well-designed E&M coding tool and a clinician who is familiar with a few simple guidelines will result in documentation that has an extremely high level of coding accuracy. Some degree of physician oversight will always be required, but properly used EHR E&M coding software has become a fundamental audit protection tool.

About the Author:

Michael Stearns, MD, CPC, CPC-FP

President and CEO

e-MDs, Inc.