Chapter 2: Planning Your EMR             

The Medical Record

The programmer that wishes to put together a usable EMR must first understand general principles about the patient medical record. A medical record, health record, or medical chart is a systematic documentation of a patient's medical history and care. The medical record can be paper based, electronic, or a combination of each, but it denotes the physical patient folder with the textual information that comprises each patient’s health history. These records are personal documents associated with many ethical and legal issues, such as third party access, appropriate storage, and appropriate disposal. Traditionally medical records have been compiled and stored by health care providers, but the personal health records are maintained by non-physician providers as well as the individual patients themselves have become more popular in recent years. The Clinical Care Record (“CCR”) initiative/standard is a good example of a personal health record.

The medical record information allows health care providers to:

*      Provide continuity of care to individual patients.

*      Serve as a basis for planning patient care, documenting communication between the health care provider and any other health professional contributing to the patient's care.

*      Assist in protecting the legal interest of the patient and the health care providers responsible for the patient's care.

*      Document the care and services provided to the patient.

*      Serve as a document to educate medical students/resident physicians.

*      Provide data for internal hospital auditing and quality assurance.

*      Provide data for medical research.

*      And to combine many of the above features with portability, thus allowing a patient to share medical records across providers and health care systems.

Medicals records have traditionally been written on paper and kept in folders, each folder divided and organized into useful sections, with new information added to each section chronologically as the patient experiences new medical issues. The most active records are usually housed at the clinical facility, but older records (e.g. those of the deceased) are often kept in separate facilities. Every state has laws which delineate exactly how long the medical record should be kept, but usually 6 years is the usual parameter for adults and longer periods for pediatric patients. In the United Kingdom, medical records are required for the lifetime of a patent and legally for as long as the time that complaint action can be brought. Generally in the UK any recorded information should be kept legally for 7 years, but for medical records additional time must be allowed for any child to reach the age of responsibility (20 years). Medical records are required many years after a patient’s death to investigate illnesses within a community.

The general content of the medical record will depend on the document that is being produced. It usually contains:

*                  The patient's identification information.

*                  The patient's health history (the history as detailed by the patient).

*                  The patient's medical examination findings (objective exam findings).

*                  Other information which may include lab test results; medications prescribed; referrals ordered to health care providers; educational materials provided; and what plans there are for further care, including patient instruction for self-care and return visits. In some places, billing information is considered to be part of the medical record.

The Database application

A database application is a type of computer application dedicated to managing a set of tables full of indexed information. Database applications span a huge variety of needs and purposes, from small user-oriented tools such as an address book, to huge enterprise-wide systems for tasks like accounting. The term "database application" usually refers to software providing a user interface to a database. The software that actually manages the data is usually called a database management system or (if it is embedded) a database engine.

Examples of classic database applications include Paradox, MySQL, Access, dBase, FileMaker and Oracle. What is covered in this book is the use of Word’s VBE to make a full-fledged database application.

The first issue that needs to be understood prior to initiating your EMR is the concept of the application life cycle. This chapter will cover phases 1 and 2- the planning and gathering of information for your EMR as well as designing the EMR interface. It’ll also offer a brief review of the other phases, all of which will be discussed in more depth in succeeding chapters. The complete EMR application life cycle which will be discussed by this book include:

1.                  Planning and Gathering Information for Your EMR.

2.                  Using Pen and Pencil to Construct Backend Tables, Userforms, and Other Objects.

3.                  Designing the Back-end Tables.

4.                  Designing Word Templates.

5.                  The VBE: Modules.

6.                  The VBE: Applying the Power Of Automation With VBA.

7.                  The VBE: Userforms.

8.                  The VBE: Toolbars.

9.                  Adding the Power of Interconnectivity.

10.              The VBE: Tapping into The Windows Interface With API Calls.

11.              Complying With Regulations and Standards.

12.              System Testing And Documentation.

13.              Packaging, Distributing, and Implementing Your Application.

These tasks do not have to be incorporated in a sequential manner, and some, s.a. documentation, could be incorporated throughout each and any phase of the developmental cycle. Some external factors that may affect the focus onto any particular aspect of the development may include end-user needs, time tables, deadlines, and budget realities. You need to realize that the EMR developmental process is a continual ongoing process. Keep your initial vision limited and manageable. Once deployed, you can upgrade your EMR with features as time passes and requirements change. The first 2 sections will be discussed in this chapter; the rest will be discussed in more detailed chapters with the same heading. This book will be a project which will be developed over the next few weeks to months, so check in frequently and please notify me of any errors and omissions.

Planning and Gathering Information for your EMR

The conceptual design phase involves using and pencil.  You begin by setting up a treeview design of tables, forms and reports.  You may need to discuss the application design with your partners and other staff members of your clinic to get their suggestions on what processes need be automated. At this time it is also important to divide the project in several different prioritized developmental processes, delegating the most important key processes first, s.a. the billing modules, the appointment scheduling, and the prescription writing modules.

The very first phase of development involves determining your immediate needs, and which modules you need to develop so as to make it easier for you to see your patients in a more efficient manner. Issues that you need to review are:

1.                  The hardware that you’ll need to purchase and set up before deploying your final EMR product.

2.                  You will need to take into consideration overall application size which will determine how much to spend on the back end software or container for your patient information.

3.                  The number of users that will be using your EMR at any given time, or the volume of activity.

4.                  The overall user interfaces, or the “look” of your application.

5.                  Recognize the application priorities- which modules need to be developed first. Most of the time you may wish to have your billing (PMS, or practice management system) activated so that at least you could bill for patients seen while putting together your EMR.

6.                  Determine which programming languages and software will need to be used in order to achieve your needs. For example, in Office 2003, you will need to learn / use VBA (“VBA”) and possibly the Extensible Markup Language (“XML”).

7.                  Integration with other applications- you may wish to purchase a separate PMS program rather than reinventing the wheel and simply integrating it via an ODBC interchange/connection.

8.                  Determine which types of data entry will be used for your application- touch screen, keyboarding, scanning, voice recognition, etc.

9.                  Determine any governmental or industry rules, regulations, and standards. These standards most recently have reviewed areas such as data validation, data integrity, and universal data standards.

10.              The ability to perform audit trails on patient information is an important aspect of the project.

11.              The manner in which help will be made available to the end users.

12.              Backing up your data- you have to ensure that your patient data will be safe and secure.

Overall, you need to understand that the application life cycle is a logical, serial progression of your EMR development.

Applying this Tutorial to Your EMR Project

          At this point, begin general planning and decide on the equiptment that you will use, the time that you will have to dedicate to the EMR development project, and make a worksheet that delineates the approximate costs of digitalizing your office.

Go to Main Bibliography Page

 

Go To Main Bibliography Page

 

Contents:

The Medical Record

The Database application

Planning and Gathering Information for your EMR

Designing a Good Table Database Design

Applying this Tutorial to Your EMR Project

 

Back to Top
Back to Top
Back to Top