Lookup Tables

Before an EHR is ready for go-live, several lookup tables must be built. There must be a way to link insurance files to patients. Billing codes must also be available if any billing is to be done through the system. Even if no billing is done, the visits must all be coded appropriately. Medications must also be coded in order to do any sort of clinical decision support, and to provide structured data for reporting.

Insurance Tables

Table population in OpenEMR or any EHR can be a tedious process. In some cases, as in the clinic used to design this workflow, there is a source for demographic and billing information available to import. In building a demographic table, the lookup tables will need to be populated before the import to establish the primary key for the insurance table corresponding to the insurance pane in OpenEMR.

Importing insurance tables

Two tables regarding insurance are involved in OpenEMR. One contains the names of the insurance company, and the other contains contact information. Through the GUI, these are seamlessly populated through the search/add insurance option that can be accessed through the patient demographics. They can also be accessed from the back end through the administration database option, which provides an interface for manipulating database tables.

If the practice is fortunate enough to have a clean data set from another source, the process would be to import the insurance names in the "insurance companies" table and the addresses in the "addresses" table with a script. The patient demographics table then can be imported next with linkages to the insurance companies.

If no database of patients exists, another method would be to acquire a set of data including insurance information and contacts. This could come from the state or from an associated practice. The drawback to this is that many insurance companies in the list may not be relevant for the clinic's patients. This would result in clutter in the insurance drop down list, making the task of selecting the correct insurance for a particular patient difficult for the office staff.

Entering insurance tables

An alternative process would involve using the information in the patient charts to seed the insurance table. This would involve manually gathering the information from the copies of the cards in the charts. A sample of recent patients carrying about 20 of the most common plans could be entered into the system in advance. This may reduce the burden of entering them during the first week of live use of the EHR.

This is an art, more of a "fuzzy" method, but it involves the least time expenditure versus benefit. Planning is necessary to create a clean database of insurance plans.

• Compile a list of insurance groups that are most common. Billing and office staff can assist in compiling a list of common insurance plans.
• Common employers could be identified, and the information for these employer plans could be entered.
• A naming convention should be laid out before beginning this task to help avoid duplicate entries in the future. The field for the name of the insurance is limited to 30 characters, so abbreviations may be necessary.
• Decide on the use of the note field, and any other fields that may be ambiguous in the particular practice.
• Decide which phone numbers are to be entered, as there are often several numbers on the card. Some web research might be needed to compile the information.
• Go directly into the MySQL administration menu in OpenEMR and enter these identified plans.
• When the data is entered, decide if the naming convention is adequate. Change any fields if necessary before starting to enter patient demographics.
• Subsequent insurances can be added on the fly, using the previous conventions as a template. A "cheat sheet" can be made for the office staff.

The pre-population of insurance tables will achieve a purpose of saving time for the office staff. This may save needing to have additional staff brought in to assist in go-live tasks. The time invested in pre-population should not exceed the estimated time savings, but it is important to consider the cost of interruptions to normal workflow.

Building Lookup Tables

Before an EHR is ready for go-live, several lookup tables must be built. There must be a way to link insurance files to patients. Billing codes must also be available if any billing is to be done through the system. Even if no billing is done, the visits must all be coded appropriately. Medications must also be coded in order to do any sort of clinical decision support, and to provide structured data for reporting.

In OpenEMR, these tables are not populated with the default installation. There is an import process, and it varies by the type of OpenEMR installation method used.

Before making a major change to the database such as a data import, the procedure must be done in a test environment. The system must be backed up, both the MySQL database and any of the web pages if there is customization to the OpenEMR software.

The test environment installation was on Ubuntu 12.04. The Ubuntu installation method for OpenEMR was used. It is recommended to use the exact distribution of Linux, the same installation package and configuration of OpenEMR, and the same version for a true test environment.

SNOMED: Access to these codes is provided with a UMLS license through the US National Library of Medicine. This information is updated biannually. OpenEMR has instructions in Administration > Other > External Data Loads. A login to UMLS is required to download the raw data file. The directory ~/openemr/contrib was created, and once access to the file is given it will be put in ~/openemr/contrib/snomed and the codes can be imported using the import utility. It will then be activated at Administration > Database > Import.

RxNorm: This import is done like the SNOMED import. The file can be downloaded from the UMLS website. It will be placed in ~/openemr/contrib/rxnorm and imported using the import utility. It will then be activated at Administration > Database > Import. The information is updated monthly.

ICD-9: In the model clinic, the test environment installation was on Ubuntu 12.04. The Ubuntu installation method for OpenEMR 4.1.1 was used. The instructions were located in the Import Standard Tables wiki page. The standard load function did not work properly, so a file was downloaded and imported at Administration > Database > Import. The code type ICD9 was found to be active by default. ICD-10 codes can be imported in the same manner.

CPT: These codes are proprietary and must be purchased. The AMA provides ASCII files for download here.

Other supporting tables can be manipulated in the Administration > Lists, using the drop down menu to select the table to be altered.

E-prescribing

Successful e-prescribing is required to meet the Meaningful Use incentive criteria. If the system is to be used meaningfully, it is recommended to incorporate e-prescribing into the practice. OpenEMR has the capability to perform e-prescribing.

In order to e-prescribe, the practice must be registered with Surescripts. This endeavor is not practical to complete as a single entity. NewCrop is a clearinghouse that can connect practices to Surescripts, paying the overhead costs for the contract. This interface can create an environment in which the master list of medications a patient is prescribed through e-prescribing can be displayed, regardless of which provider prescribed it.

Benefits to e-prescribing for include:

• Drug-drug/drug-allergy checks
• Active medication list
• Potential benefit to patients:
  • Potential to save time managing phone and fax prescription renewals
  • May reduce adverse drug eventsthrough clinical decision support and master drug lists.
  • Opportunities for formulary or generic cost savings may save patients money.

Further benefits to e-prescribing and details can be found in the AMA Clinician's Guide.

A consideration to be made involves custom prescribing. Compounded medications and prescriptions requiring complex instructions or titrations might be problematic through the e-prescribing interface. A possible solution would be to have e-prescribing occur through default for the majority of prescriptions. The prescriptions that cannot be accurately delivered by the e-prescribing interface can instead be entered using a custom form and sent via fax or printed for the patient.

The alternative to e-prescribing would be to preserve the status quo. A form within OpenEMR could be used to create faxes or printed prescriptions for the patient. Alternately, the prescription could be handwritten. This option would not meet the requirements for meaningful use.

Populating all possible tables ahead of time can markedly reduce the workload in the first few weeks after transition to OpenEMR.