7. Business Requirements
for an Automated Patient Medical Record

7.1 Project Context: Deriving Business Requirements

Business requirements are required characteristics of an organization at the end of a project. Business requirements are primarily derived from the following sources: (1) from identification of current automated systems and business practices to be preserved, (2) from project objectives, (3) from a vision of the future, (4) from improvements suggested by employees and others, (5) from projecting how the future environment and systems will function, (6) from identification of obstacles to the project.

The first three ways for deriving business requirements were discussed in previous chapters. This chapter identifies business requirements derived from project objectives. See figure 7.1.

A conceptual view of the automated patient medical record system so far is presented in figure 7.2, combining the conceptual view of section 5.6 with a universal patient record. At the end of this chapter in section 7.9, a new conceptual view of our project is presented that incorporates the business requirements in this chapter.

Since a business requirement, like a project objective, may not, as stated, be measurable, it is also useful to identify a goal for each business requirement. Goals for project business requirements, including business requirements presented in this chapter, appear in section 10.16, later in this book.

7.2 Source Documents in the Automated Patient Medical Record

The basic medical information included in the automated patient medical record will continue to be in the form of source documents. This information in the automated system may change structure and be organized differently, but these source documents are likely to be the same ones as listed in section 4.4.3 of this book.

Source documents can be in the form of text, fax, voice, graphics, picture or video, or any combination of these, with embedding of graphics or pictures within the text or link to an item within the text.

7.3 Organizing the Automated Patient Medical Record

One project objective listed in figure 5.8 is to enable a caregiver to quickly find relevant information in the patient medical record by methods such as providing summarization information, organization, information retrieval and tailoring of information related to the type of caregiver.

The following are proposed methods for organizing the automated patient medical record:

1. encounters: Each document in the medical record is associated with the encounter (e.g., outpatient visit, inpatient stay) in which it was created

2. significant health problems: An encounter is associated with a significant health problem, so selection of the health problem identifies all the encounters where care for the health problem occurred.

7.3.1 Encounters

A natural and seemingly straightforward way of organizing documents making up the patient chart is to categorize source documents and other patient clinical information as to whether they apply to an

· inpatient stay, including hospice, SNF, subacute care facility, etc.

· outpatient visit

· emergency department (ED) visit

· surgery

· phone call consult that takes the place of an outpatient visit

· e-mail consult [1]

· observation visit

· home health care visit.

Each of the above is an encounter. The ASTM (American Society for Testing and Materials), which develops and publishes standards on a wide variety of topics in health care informatics through the ASTM E31 committee, defines an encounter as “an instance of direct (usually face-to-face) interaction, regardless of setting, between a patient and a practitioner vested with primary responsibility for diagnosing, evaluating or treating the patient’s condition, or both, or providing social work services. (Encounters do not include ancillary services visits or telephone contacts.)” [2]. (The ASTM definition would thus not include phone call consults, and also would probably not include e-mail consults, as encounters. This book considers a telephone contact to be an encounter if the telephone contact is significant enough to take the place of an outpatient visit and if either a physician-patient relationship has already been established or one will be established in the future [3].)

Associating each clinical document with an encounter would enable a caregiver to select all patient clinical information associated with a particular encounter. Although the use of an encounter to categorize a document is useful, there could be some possible complications in doing this tying of documents to an encounter, although I think all these complications can be overcome.

Consider an inpatient visit. Sometimes diagnostic tests are done prior to admission, in particular prior to an admission to the hospital for a surgery. If it is deemed desirable to associate the diagnostic tests done prior to the admission with the inpatient stay, then these tests must be temporarily associated with some data item other than the admission, perhaps with a pre-admission, and then later tied to the admission. A further complication is that the admission may never occur.

Another possible complication occurring with an inpatient stay is the chance of a temporary transfer of a patient to another location while the patient remains admitted in the first location. An example is the transfer of a patient for a cardiac catheterization in a second facility, while still being considered admitted to the first facility.

There are also possible complications with tying documents with an outpatient visit. During an outpatient visit, there may be orders for diagnostic tests and for treatments. Usually these tests and treatments take place after the outpatient visit is complete. These tests and treatments even could occur at a different facility and prescriptions could be filled at a non-HMO pharmacy. Thus tying together documentation of a test result, treatment, or the dispensing of a medication with the outpatient visit may require some sophistication in the computer systems involved and possible computer network communication between facilities.

Also, outpatient diagnostic tests could be done prior to the outpatient visit. Such tests might have to first be associated with an appointment and then with the outpatient visit. Again, as with the inpatient situation, the outpatient visit could fail to take place.

There are a number of types of documents that cannot always be tied uniquely to one encounter, including phone messages and e-mail messages. Phone messages and e-mail messages dealing with patient clinical information can occur prior to encounters and independent of encounters. Documents listed in the next section, section 6.4, cross encounters and also cannot be tied to a single encounter.

The identification of encounters as well as the start date/time and end date/time of an encounter usually comes from other HMO computerized clinical systems independent from the automated patient medical record system. Another value that could come from these systems is an encounter status, an event that may logically precede, occur during or be a result of an encounter or potential encounter, or event that is a result of a situation causing the encounter not to occur.

Types of encounters and associated encounter statuses are the following:

· inpatient stay (with status pre-admitted, admitted, admitted—newborn, transferred to another location or facility, scheduled for discharge, discharged, transferred while retaining admission, case abstract after discharge creating codes for the diagnoses, admission reversal, etc.--and also post hospital outpatient visit) from the ADT system or other systems (e.g., for SNF admissions)

· outpatient visit (with status wait-listed, appointed, appointment canceled, appointment no show, patient registered, in the examination room, visit completed, diagnoses and procedures identified) from the appointment system, from the registration system (to collect co-payments and record the patient has come in for a visit) or from other clinical systems

· ED visit (with status patient registered, in the examination room, discharged from ED to home, discharged from ED to hospital, diagnoses and procedures identified) from the ED system and/or Registration system

· surgery (with status scheduled, in progress, completed, canceled, case abstracted) from the Surgery system

· phone call (with status pending, completion of a non-encounter, completion of an encounter) -- potentially from the appointment or registration systems, but, as stated earlier in this section, the ASTM E31 committee does not consider telephone contacts to be encounters [2]

· observation visit—entrance to a medical facility for observation (with status recorded, returned to home, admitted to hospital) from the ADT system (e.g., a pregnant woman in the early stages of labor may be brought in for an observation visit after which she may be sent to labor and delivery or to home)

· home care (with status care at home, termination of care at home).

Sometimes the associated encounter information is unavailable to the automated patient medical record system before a document is entered. This might be due to the encounter clinical system (e.g., ADT, the appointment system or registration system) being down, its network connection with the automated system being down, or due to the encounter not yet being entered into the encounter system. In such cases, the tying of the document to an encounter might have to occur later, after the encounter is later received.

Some events could occur a long time after the encounter, and, if it is necessary to record them in the automated patient medical record, it may be difficult to associate them with the encounter. For example, a physician could review the automated patient medical record to determine whether a medication should be reordered. The encounter where the medication was ordered could have occurred a long time ago.

At the beginning of automation of the chart, especially with an HMO with point of service contracts, some facilities or associated healthcare institutions may not be part of the automated system, and associating documents and orders with encounters in these facilities or outside health institutions may not be possible, at least not until there is a universal patient record.

Despite possible complications with doing so, associating each patient medical record document with an encounter appears to be a useful and necessary first step in organizing the patient chart.

7.3.2 Significant, Persistent and Long Lasting, Health Problems

Often a patient comes in many times for a significant health problem (hypertension, an allergy, asthma, urinary incontinence, a prostate problem). For a caregiver to have a list of these significant health problems is extremely useful.

But in addition, identification of such significant health problems could also help organize the patient medical record so that encounters associated with that problem can be found, so that patients could be identified to be given health education on a problem, and so that similar but more severe problems can be anticipated (e.g., obesity may be associated with diabetes, BPH symptoms may be similar to symptoms for prostate cancer). A previous attempt at organizing the patient chart by significant health problems is the Problem-Oriented Medical Record (POMR) [4].

The automated system could identify or help identify such persistent health problems and caregivers could be trained to identify such health problems.

7.4 Documents to Track Care Across Encounters

One project objective listed in figure 5.8 is to track care across multiple encounters. This includes identifying trends in a patient’s health (e.g., significant increases in a patient’s blood pressure). For purposes of continuity of care, it is important to track care that may occur across encounters, possibly with different caregivers, in different medical facilities, and in different healthcare organizations.

A model for patient care, both for inpatient and outpatient care, was presented in figure 4.3 [5]. As shown by this figure, the process of care is as follows: The patient is identified and the problem (referred to as the “chief complaint”) is recorded. Through various means, the caregiver hypothesizes on the diagnosis. Based upon a selected diagnosis, the caregiver develops a treatment plan for the patient, observes the results and may refine his or her hypotheses and diagnosis. After the caregiver observes the results, the diagnosis or treatment may be changed. This process often occurs over many encounters.

In order to accurately record the care process in the patient chart when there are many encounters for the same treatment, I propose that a case management approach be used, with a case referencing the encounters spanning the treatment of the patient for the medical condition. A case to track a treatment for a particular patient and usually non-chronic medical condition over a number of encounters where the condition is not likely to require long term continuing care, I will refer to as a defined outcome case, as the expected, and finally the actual, outcome needs to be identified along with the treatment in order to evaluate the treatment. A case to track a patient who is being treated for a chronic condition over many encounters where there is likely to be long term continuing care, will be referred to as a chronic care management case. Defined outcome cases differ from chronic care management cases in that the former are expected to have a concluding outcome (e.g., the condition is relieved, goes away or is cured), while the latter would have periodic outcomes (e.g., the number of hospital stays during the period). An important care activity in a chronic care management case are patient education visits where the member is educated on when it is appropriate for the member to administer self-care for his chronic condition and when it is mandatory that the member come in for care.

Also, I propose that there be a type of case, a patient case, which can be used for management of high-risk and high-cost patients. Such a case can be created independently from any specific medical condition. A patient case would be useful for Worker's Compensation patients and Medicare patients to track patients and reduce costs.

Types of documents to record care across multiple encounters are the following:

1. Case management document: A document that associates encounters for a named patient for some reason: a defined outcome case, a chronic disease management case or a patient case.

2. Trend document: A document recording a clinical value for a patient collected over various encounters.

3. Clinical pathway document: A document generically describing a "standard of care" given over multiple encounters, based upon a particular medical condition, which may be applied to a patient with this condition.

The entity-relationship (E-R) diagram in figure 7.3 proposes a structure fo a case—section 13.7 describes how to interpret E-R diagrams. Defined outcome cases and chronic care management cases would consist of a list of case managers; a description of the treatment plan with any later changes to it, including treatment notes for each encounter; expected outcomes of the treatment, may include references to documents describing the treatment plan in detail such as clinical pathway documents and treatment guidelines (e.g., AHCPR Clinical Practice Guidelines [6]); and may include a document I call a “trend document”. The case document would identify encounters associated with the case and might also include case notes and other documents entered and used by an overall case manager, who together with a physician might oversee the case. Eventually, the actual outcomes of the treatment would be associated with the case, so the treatment could be evaluated; three types of outcomes need be considered: financial, clinical and patient satisfaction.

A patient case allows a case manager to track a patient over multiple encounters, whether or not the encounters are for a specific medical condition. A patient case may stand-alone or may be part of a defined outcome or chronic disease management case. It would consist of case notes and other case documents, as part of overall case management information (see figure 7.3).

Defined outcome cases and chronic care management cases tie together all the documents and encounters associated with care of a patient for a particular condition, whether the encounters are inpatient, outpatient, Emergency Department or other type of visits. Defined outcome cases and chronic care management cases should clearly identify treatments given, care plans followed and patient characteristics (e.g., the condition of the patient at the start of treatment). And defined outcome cases and chronic care management cases should record expected and actual outcomes of these treatments.

After defined outcome cases for similar medical conditions and similar patients have been completed, various treatment plans for the same health problem can be evaluated for the most favorable outcomes and thus the best treatments, supporting what has been called “evidence-based medicine” [7]. Results of such studies could produce treatment plans that result in best medical practices, those with the greatest chance of success at the least cost and the greatest benefit to the patient.

Outcomes of chronic care management cases for chronic conditions could involve comparing costs, quality and patient satisfaction results for patients being tracked by chronic care management cases with patients with the same chronic disease who are not being tracked to see if there is a measurable impact of the care plan. Alternative successful care plans can be compared. Through this process, care plans can be chosen that best improve the care of patients for these chronic conditions. Defined outcome cases and chronic care management cases thus provide a means to evaluate and improve medical care.

The case management approach can also be used for automated evaluation of care, with system determination that care being given may be inconsistent with a treatment plan or best practice guidelines, or that inappropriate medications or treatments were being given. The case manager could be notified by the system, who then could consult with practitioners to verify that proper care was being given. Also, practitioners who need to be retrained could be identified.

A chronic care management case, and possibly a defined outcome case, can be associated with a significant patient health problem. The list of significant health problems for a patient could then identify which problems have associated case(s).

Ideally, defined outcome cases, chronic care management cases, and patient cases will become part of the CPR repository so that cases can be tracked, and possibly managed, across health care organizations. Supporting documentation, such as clinical pathway documents, should also being captured, e.g., in the source document repository.

Defined outcome cases and chronic care management cases require a new discipline of care. A treatment plan in a defined outcome case or chronic care management case may be set up by one caregiver and generally needs to followed by later caregivers who see the patient, even if the later caregiver has a different style or philosophy in providing care. If the same caregiver continues to see the patient, change in care philosophy is not a problem and thus is usually the preferred situation; assignment of a patient with a limited number of physician(s) or nurse practitioners, a “care team”, who oversee the patient’s care and understand each others’ care philosophy is an alternative approach that may work well.

Some analysis has to be done to determine what should happen if a physician sees the patient for a second opinion on a disease, condition or treatment. For example, should the physician providing the second opinion review a defined outcome case or completely ignore the defined outcome case so he isn’t biased by the treatment given by the other caregiver(s)?

Use of defined outcome cases and chronic care management cases require discipline and some extra work by physicians and other caregivers, but has tremendous benefits to patients, to healthcare organizations, and to society as a whole.

7.4.1 Defined Outcome Case

A useful concept is an episode. The ASTM defines an episode as “one or more healthcare services received by an individual during a period of relatively continuous care by healthcare practitioners in relation to a particular clinical problem or situation” [2].

As evidenced by figures 4.3 and 4.5, treatment of a particular health problem is an iterative process, possibly extending over many outpatient and inpatient visits. This is true of almost all significant health problems.

Automation of the chart allows for the possibility of clear communication of a treatment extending over many encounters with expected outcomes of the treatment, and eventually the final outcome of the treatment. By HMO personnel consciously identifying these encounters as part of a treatment and tracking the treatment, long term patient treatment plans could be better managed, evaluated and be more successful, resulting in much improved patient care. A proposed set of documents to document such a treatment for an acute (i.e., short duration) condition will be referred to as a “defined outcome case” because the treatment can be best managed by case management techniques and can be evaluated by identifying the final outcomes of the treatment.

The following describes the characteristics of a defined outcome case:

· when a treatment for acute care extends over more than one encounter, a defined outcome case can be developed with treatment plans and treatment notes explaining the treatment and follow-up notes being attached by later caregivers to identify continuation or change of the treatment

· the defined outcome case can optionally reference national or HMO clinical practice guidelines (e.g., from the AHCPR National Guideline Database)

· for a defined outcome case, an optional clinical pathway document based upon the patient condition can be attached, guiding the treatment

· for a defined outcome case, an optional trend document can be used, that automates collection of particular data values, such a blood pressure over the various encounter, growth charts (height and weight), etc.

· each encounter associated with the defined outcome case will be identified.

A defined outcome case should be assigned to a case manager to enable the case manager to track the treatment. The case manager may be the patient’s principal primary care provider or other caregiver. Through the defined outcome case, assigned caregivers and/or the case manager could optionally be notified if critical events in the defined outcome case fail to occur.

7.4.2 Chronic Care Management Case

According to a reference on the Internet [8], 60% of the healthcare claim costs in America are for chronic (long lasting) diseases. Management of chronic diseases often requires long-term treatment management controlling costs and patient accessibility to services. The assignment of a case manager could assist the patient in accessibility to services. Such a case will be referred to here as a “chronic care management case”.

Examples of diseases possibly requiring long term management are the following:

· HIV/AIDS

· asthma

· diabetes

· severe depression

· chronic obstructive pulmonary disease

· seizure disorders

· renal disease.

A number of health organizations provide disease management advice or services [9,10,11]. For example, the Nation Jewish Medical and Research Center [11] provides disease management services for asthma, COPD, bronchitis, and emphysema; a graph demonstratively shows significant savings for disease management of asthma.

As part of a chronic care management case, a clinical pathway could be developed that combines case manager activities together with physician, nurse, pharmacist and other caregiver activities. Through the clinical pathway, a patient could be assured to be given the right medication at the right time and the right treatment. Any national or HMO clinical practice guidelines that are being followed could also be referenced.

Patient compliance with showing up for treatments and following prescribed drug therapies in the chronic care management case could be tracked. For example, through the automated patient medical record system, caregivers could be notified when a patient misses an appointment (and thus misses a treatment) and when medications are not picked up from the pharmacy. In the future, chronic care management case tracking of patients could be supported by “Guardian Angel” computer systems in the patient’s possession to track patient compliance with treatments (see section 5.4.3.6).

7.4.3 Patient Case

It is often useful to assign a high-cost or high-risk patient (for example, an elderly, frail Medicare patient or a patient paid for by workers’ compensation) to a case manager whose job is to guide the patient through the system, determining the most appropriate treatments or health care entities (SNF’s, hospices, etc.). Such a case will be termed a “patient case”, as case management of the patient may occur across many patient encounters that may not be related to the same treatment or chronic condition.

Documents necessary to support this tracking of high cost, high risk, patients should be stored by the automated patient medical record systems as a “patient case”. At the very least, these documents should include case notes for recording of notes by the case manager, which can optionally be associated with patient encounters.

Chronic care management cases or defined outcome cases can be combined with patient cases.

7.4.4 Trend Document

A trend document automatically records a value that a caregiver wants to track over time as they are input via other source documents. Examples are blood pressure readings, blood glucose readings and patient’s height and weight. A trend document may either stand-alone or be part of a defined outcome case or chronic care management case.

Whenever the patient comes in, the automated patient medical record system could prompt the caregiver to record that required value. Additionally, patients could call into the healthcare organization to have recorded their own blood pressure readings, blood glucose readings, etc. See figure 7.4 for an example of a trend document for blood pressure. Trend documents may also stand alone, independent of defined outcome cases or chronic care management cases.

Trend documents, like in figure 7.4, could also record mean, maximum and minimum expected values for what is being measured, for example mean, maximum and minimum systolic and diastolic values for males varying by age. They could be set up to be actionable, i.e., to automatically inform identified caregivers when a measured value is out of range. A trend document as described is referred to as a control chart [12] in the field of statistical process control.

7.4.5 Clinical Pathway

A structured approach to patient care is a clinical pathway (sometimes called "critical pathway" or "life care path") document. A clinical pathway encapsulates a care or treatment plan for a specific condition or encapsulates preventative care for patients in a particular category.

A clinical pathway identifies care activities and caregiver workflow needed to care for a patient with a particular condition or disease. Paths through a clinical pathway can be adjusted for the particular needs of an individual patient.

A clinical pathway document may stand alone or be part of a defined outcome case, chronic disease management case, or a patient case. It describes a series of care activities that may be conditionally performed that as either part of a treatment (e.g., for Alzheimer's, kidney stones) or part of a strategy for preventative care (e.g., preventative health activities to be performed on the patient of such a sex and age such as mammography). The latter type of clinical pathway identifying preventative care for a member is termed a "Life Care Path", as it exists over the life time of the patient, not just during a specific treatment.

A clinical pathway identifies a standard of care for caregivers for a particular patient problem or condition with consideration of risk adjustments which may be based upon patient psychological, health and social factors, family/genetic history, patient age, race and sex. A clinical pathway may exist for outpatients, inpatients or both [13, 14]. A clinical pathway may be used for treating illnesses or for managing health and wellness (and may then be known as health paths or life care paths). For example there might be a clinical pathway for all female patients over 50.

A clinical pathway consists of the following elements:

· Clinical pathway Template: a network structure diagram identifying all recommended alternative paths of care based upon intermediate goals and outcomes. A clinical pathway template consists of a series of care activities, paths between care activities, and optionally times between care activities in a path as identified by fixed time values or by probability density functions (pdf) identifying likely time values, with one time or pdf for the organization and one for the health care industry as a whole. From one care activity there may be one or many paths leading to other care activities. A number of care activities could lead to the same care activity. Network diagram paths eventually may lead to final outcomes that identify the conclusion of the care path (e.g., discharge from the hospital), or paths may be ongoing. A care activity may consist of text identifying care to be given, a goal, an order or appointment to be automatically scheduled, a protocol defined elsewhere in the system (e.g., "Implement 'anticoag' protocol"), or another clinical pathway; for example, there may be a clinical pathway template identifying all likely paths for care activities for women over 50, including paths identifying that the patient has been confirmed as having breast cancer and thereafter treating the patient, with a care activity consisting of a different clinical pathway specifically for the treatment of breast cancer. There would be another path identifying that the patient is healthy. One possible final outcome in the breast cancer clinical pathway may be total remission of the cancer.

· Selected Path: one of the paths through the clinical pathway template selected by caregiver(s) upon intermediate outcomes, goals, and final outcomes, identifying care to be given to the patient as determined by the clinical pathway template. During an encounter between the patient and a caregiver, the caregiver can select the next path to take in the clinical pathway template based upon a goal or an intermediate patient outcome. For example, a clinical pathway may include a care activity that consists of giving the patient a mammogram, with the intermediate outcome that the patient has a normal mammogram, and thus the patient would be scheduled for the next care activity, a mammogram a year later.

· Actual Path: a path identifying actual care activities given to the patient, which tracks the outcome-directed "selected path" except that actual times, if applicable, may be assigned to paths, care activities may be added or skipped, additional intermediate and final outcomes may result. The actual path identifies what actually happened; it may consist of the same path as the outcome-directed path but with actual times between activities or additional care activities within the path.

· Variances: each variance between an actual path and a selected (projected) path, in time, care activities, order of care activities and costs and variance between actual and projected immediate outcomes; the variance between the actual final outcome and the initially projected final outcome [13].

During an encounter of a patient with a caregiver, the caregiver can identify the next path to take, adding to the selected path. The next care activity in a selected path may be an encounter and optionally include automatic scheduling of the encounter or may put the encounter on a wait list for later scheduling of the encounter. A care activity in a selected path may also optionally automatically schedule an order. The caregiver may be informed if a care activity is not performed within the required time (e.g., a patient with a critical condition does not show up for his appointment and does not reschedule the appointment in the required time). The caregiver can add or skip care activities changing the selected path, and creating an actual path different than the selected path.

After assignment of a clinical pathway to a patient, a clinical pathway can be discontinued, merged with other clinical pathways or identified as completed by a caregiver. Merging of clinical pathways would take into account comorbidity, i.e., interaction of the care activities in multiple clinical pathways. Care activities in different clinical pathways that are merged could be color coded by the clinical pathway the care activity came from and highlighted for co-morbidity. As paths through the clinical pathway are completed, times for actual paths would be included in with the pdf's for the organization in the clinical pathway template.

A clinical pathway structure could also include care activities that a patient himself or herself is advised to follow (e.g., a drug therapy program for the patient).

7.4.6 Care Management Versus Case Management Versus Disease Management

It is useful to distinguish between care management, case management and disease management, although these types of management of patients and patient care overlap. The following are definitions:

· case management: An organized system for delivering health care to an individual that includes assessment and development of a plan of care, coordination of services, referrals and follow-ups.

· care management: Aggregates encounters and other events into episodes for a particular occurrence of a medical condition, possibly across care settings, rather than just focusing on a single encounter or event of an illness or injury.

· disease management: Identifies populations (patients) with particular acute and chronic diseases, such as diabetes, cancer, coronary artery disease or asthma, and introduces interventions throughout the life cycle of the disease that would both improve the patient’s quality of life and lower the costs associated with the disease process.

These categories of care are not mutually exclusive of each other. Care management and disease management are encompassed by case management.

Defined outcome case documents, chronic care management case documents and patient case documents are documents that can be used for case management. Defined outcome case documents apply to care management, as they are intended for episodes for a single occurrence of a medical condition. Patient case documents are intended for case management of high-risk patients, where case management is done independently of the medical conditions being treated. Since disease management generally tracks chronic diseases and potentially chronic diseases, chronic care management case documents are most useful for disease management.

7.5 Putting Together a Distributed Patient Chart

One project objective listed in figure 5.8 is to create a complete and always available patient medical record. There are lots of possible ways of storing an automated patient medical record.

With automation of the patient medical record, an HMO can eventually consolidate all their chart information in a single data repository in the HMO, if they so choose. Thus, the example of the many charts for a patient in an HMO as shown in figure 4.8 could change so that this clinical information could be combined into a centrally located computerized patient medical record. Or the patient medical record information could be combined into a repository completely outside the HMO.

Even if alliance and other healthcare organizations are completely automated also, they would likely store all their information outside the HMO. With complete automation of the chart, where the automated patient medical record is actually stored could be transparent and irrelevant to the user as long as the technology to retrieve it is fast enough.

But patient medical record information outside the HMO is likely to be, at first, on paper. And during the interim phases of automation of the HMO’s own patient medical record, HMO clinical information is likely to be both automated and on paper.

So, in summary, with an automated patient medical record:

· as long the technology is fast enough to retrieve the parts of the automated patient medical record, it doesn’t matter whether the automated part of the chart is stored, in many locations or only one, as the user would not notice any difference

· however, part of a patient’s medical record is likely to be on paper.

7.5.1 A Prediction of the Future

At this point, the author will reiterate and expand upon some predictions made in the last chapter about the storage of automated patient medical records in the future. See figure 7.5.

In the future, there will be a Computer-based Patient Record (CPR) repository to store a summary of patient chart information nation-wide developed from source documents for the patient. Additionally, source documents as input by caregivers will be increasingly computerized with healthcare organizations storing these patient records electronically on source document repositories.

Source document repositories in the future could even be located outside the HMO in other organizations. (Pacific Bell, for example, has built a repository to store diagnostic images for California healthcare organizations [15].) The source document repository organization would take over responsibility for storage of clinical information, duplicate storage of clinical information at a second off-site location, and the costs of insurance for accidental destruction of the chart information.

The CPR repository could also store the location of the source documents, whether on paper in a chart room or in a source document repository wherever the source document repository is located. A healthcare organization could be informed of member medical record information added to the CPR repository for encounters occurring outside the healthcare organization and of changes in locations of source documents where the locations are outside the healthcare organization.

Whenever a healthcare organization was informed in a change to the CPR, the healthcare organization could retrieve the CPR information from the CPR repository and the associated source documents from the source document repository or other source document locations as identified in the CPR repository.

The CPR repository and source document repositories could be organized by patient and patient encounter. Upon completion of an encounter in the healthcare organization, the healthcare organization could send a summary of the encounter to the CPR repository. This information could include encounter summary items, together with current patient demographics information. Further, the healthcare organization could identify a list of patient health problems and associate encounters with these health problems. Periodically, the source documents could be sent to the source document repository, sending the changed location to the CPR repository.

If it turns out that there are multiple CPR repositories, then it would be useful to have a patient registry that receives information from CPR repositories on additions to the CPR repositories. The patient registry, rather than the CPR repositories, would then inform the healthcare organization of updates to the CPR repositories. Such CPR and source document repositories and patient registry could be structured as pictured in figure 6.5.

There are a number of standards for the structure and content of the CPR. These include ASTM (American Society for Testing and Materials) E1384-96, Medix from IEEE (IEEE P1157), and ASTM Draft E31.12-4. According to a paper, the NIH (National Information Infrastructure) Form for LM-94-002, “widespread agreement on these standards or their implementation is lagging” [16].

As a representative standard, this book will assume the ASTM E1384-96 standard for the CPR [2]. This includes the following information:

· patient demographics

· patient legal agreements

· patient financial information

· practitioners

· patient problems

· immunizations

· health history

· assessments

· patient reported data

· clinical orders

· diagnostic tests

· medications

· scheduled appointments/events

· encounters

· chief complaints/diagnoses

· clinical courses

· therapies/procedures.

Although not part of the ASTM E1384 standard, as stated here, it is proposed that each CPR repository also keep the locations of all source documents associated with the encounter. Source documents could be located (1) within a non-healthcare organization source document repository, (2) within a healthcare organization source document repository or (3) on paper within a healthcare organization. (The ASTM E1384 standard does, however, include a single location for the paper or automated patient medical record for each encounter.)

It is also proposed that a synopsis of each patient encounter be kept in the CPR repository, although, again, this is not part of the ASTM E1384 standard. For healthcare organizations that have not yet computerized the patient chart and thus cannot send any other information to the CPR, this synopsis could be sent to the CPR repository by e-mail together with an indication that the associated chart is located on paper at the healthcare organization.

Subscribers to the patient registry (see figure 6.5 again) would pay to receive notification of new encounters of interest, identifying the patients and conditions under which the subscriber would be notified. For example, an insurance company subscriber could get information on any patient encounter where the patient owns insurance issued by that company and where that insurance applies for that encounter. An HMO subscriber could get information on any encounter for a current HMO member that occurs outside the HMO so the HMO could have a complete record of the patient’s encounters and of the locations of associated documents; additionally, an HMO subscriber could pick up all patient clinical information for a patient who is a new member of the HMO and could pick up information for non-members scheduled to visit the HMO. Upon identifying the location of encounter documents from the CPR, the subscriber could later retrieve or make a request to receive the source documents from the source document repositories or from chart rooms outside the healthcare organization.

Some source documents could cross multiple encounters. Defined outcome cases and chronic care management cases could cross multiple encounters. A clinical pathway is a document that provides a care plan for a patient that may cross multiple encounters. Another type of document that I propose, that crosses multiple encounters, will be referred to here as a “trend document” (see figure 7.4). A trend document could collect and display information, possibly graphically, from values collected during multiple encounters and from values called in by the patient to an appointment clerk or advice nurse. Trend documents identify trends in the patient health based upon a defining patient condition, a significant health problem or a potential problem (a concern) to be studied. Examples are a growth chart showing age versus height for a child being studied for small stature in an endocrinology clinic, or charts showing blood pressure and serum cholesterol level versus time for a patient with cardiac problems. Clinical pathways, trend documents and references to clinical practice guidelines can be included within a defined outcome case or chronic care management case, identifying a treatment for the patient.

A referenced clinical practice guideline should be available on-line. Because a clinical practice guideline may be used by many patients in many different cases, there should be some repository for storing a clinical practice guideline one time. Also, since a clinical practice guideline might change over time, a history of these changes should also be kept (for example, with a version number for each set of changes). CPR repositories could reference these clinical practice guidelines; see figure 5.4.

As stated in section 7.4, I think that defined outcome cases and chronic care management cases (including treatment plans and notes, case notes, and references to clinical pathways, trend documents and clinical practice guidelines) should be made part of the CPR repositories. This would enable a defined outcome case or chronic care management case to be used across many healthcare institutions.

The patient registry, CPR repositories and source document repositories are the constituent parts of Patient Health Records. If this prediction of repositories and registries is correct, many standards for repositories and registries need to be developed.

CPR repositories should store information using agreed upon format standards. Source document repositories should store documents in the format of the healthcare institution of the document in order to preserve the appearance of the document; however, stored with each source document in the source document repository, ideally, should be information to translate proprietary health institution data elements to standard data elements, so other healthcare institutions could also make use of the documents. (For example, an outside healthcare institution may receive the source document in the form it appears at the originating healthcare institution with proprietary data elements highlighted; pressing a right mouse button over the highlighted data element might display a caption with the standard, translated, information.)

Although CPR repositories would store information using agreed upon standards and source document repositories might need to have information to translate clinical information based upon data standards, these standards might change or be expanded to include additional data over time. A mechanism to coordinate these changes in standards and communicate these changes to healthcare institutions needs to be established.

It is expected that some standard data elements appearing in the CPR will require a mechanism for immediate assignment at a healthcare organization, such as patient identifiers and site of care identifiers. For example, if there is a new patient to the HMO, the HMO should have the ability to do an inquiry through a remote organization who assigns such identifiers to determine if the patient already has a patient identifier and either return a newly assigned identifier or return the existing identifier. Other standard data elements not requiring immediate update might be handled via tapes listing the values for these data elements, periodically sent to the healthcare organization from the assigning organizations.

7.5.2 Standards for a Distributed Patient Chart

There have been many standards groups meeting to determine healthcare standards for the following:

· patient identifier

· provider identifier

· care site identifier

· product and supply identifier

· computer to computer communication message formats

· clinical data representation

· patient chart content and structure

· medical terminology within the chart.

See the appendix of this book for more information.

An indisputable standard for communication of healthcare information across networks is HL7. This is discussed in more detail in section 13.11.6.

7.6 Incorporating Healthcare Organization Business Policies

As stated in section 2.4.3, part of almost all projects is implementing organizational business policies in automated systems and in organizational procedures. This involves determining what parts of the business policy are implemented through code or tables, databases, user interfaces, workflows and interfaces between systems.

An HMO or other organization has business policies governing the way it works. Further, business policies may differ for different parts of the organization. For example, in an HMO, each HMO facility and each department in a facility may work differently. Departments of a particular type (e.g., dermatology, medicine, and pediatrics) might each have their own set of rules. And each provider may sometimes be able to override a business policy.

A major failing of computer system design and maintenance is that companies entrust computer people to properly incorporate business policies into a system, rather than the people in the groups who are responsible for these policies. Further, incorporation of these policies into the system may involve changes to code in many different parts of systems; thus, no matter how competent the computer people are in incorporating the business policies, maintenance of, and especially documentation of, these business policies may be extremely difficult.

It is proposed that the automated system provide a means by which such business policies can be easily implemented within the automated system by the people controlling these policies rather than computer people, with easy re-implementation when a change in business policy occurs. Thus the people responsible for enforcing these policies should be involved in the design of databases, code or tables, interfaces between systems, user interfaces and changes in workflow to implement these business policies. An agent is defined here as a way of categorizing and separating out a set of independent business rules incorporating a business policy—possibly embedded in code or tables, databases, interfaces between systems, and user interfaces through a number of different computer systems, as well as operational rules—so that the business policy can be easily changed without effecting the other code in the system.

These business policies can be business policies related to the organization, a region of the organization, a group of facilities, a facility, a department type, a particular outpatient department or hospital unit, a caregiver job category or an individual caregiver, with differing business policies for each level. Figure 7.6 shows proposal for a hierarchy of agents within an HMO, with agents with a lower priority number overriding an agent with a higher priority number. Thus a set of business rules may be defined at one level, say for the whole HMO, but be overridden at a lower level, say by caregivers within a particular job category, such as for inpatient nurses, and be overridden at yet a lower level, say by an individual named caregiver; thus, even though Nurse Jones is an inpatient nurse, she uses an agent for her individually, while other inpatient nurses use a lower level organizational job category agent for inpatient nurses.

Figure 7.6—Priority of Agents

Priority	Agent Type
1	Personal Agent
2	Unit / Department Job Category Agent
3	Unit / Department Agent
4	Unit / Department Type Agent
5	Facility Job Category Agent
6	Facility Agent
7	Facility Group Job Category Agent
8	Facility Group Agent
9	Regional Job Category Agent
10	Regional Agent
11	Organizational Job Category Agent
12	Organizational Agent

In order to perform its task, an agent may perform its work in any computer within the distributed system. Further, the code to execute the agent might be stored anywhere on the network, possibly shipped down to be executed. Such techniques would enable, say, a regional agent to be compiled and implemented only once, within the regional computer for the entire organization and not every computer, but still allow it to be used anywhere, e.g., within a local system for a particular healthcare facility.

Examples of business policies that might be implemented in the automated medical record system by agents, through code and tables, databases, user interfaces, interfaces between computers, and work flows are the following:

· A Policy for Assigning Personal Care Providers with HMO Members: A consistent policy for the entire healthcare organization could be implemented both for the automated patient medical record system and other HMO clinical systems.

· A Policy for Tailoring the System by Caregiver Type: Various types of caregivers need different types of access to the system. For example, inpatient physicians, outpatient physicians, inpatient nurses, inpatient nurses probably all require different types of patient lists. A “patient list” is a list of patients of interest to a caregiver stored within the automated patient medical record system, usually automatically built from encounters and encounter statuses from other clinical systems. See section 7.7.5 for a discussion of patient lists. An inpatient nurse needs a unit census and an outpatient physician needs quick access to his schedule. These are two, of many different types of, patient lists. An organizational job category agent could be set up based upon job category of the caregiver (nurse, outpatient physician, inpatient physician, etc.) to display the required “patient lists” for the caregiver in the format required by the particular type of caregiver. A particular caregiver could define a personal agent to present a set of patient lists different than the standard set, with the personal agent overriding the organization job category agent. Besides patient lists, other information is appropriate for tailorability by job category (e.g., patient clinical summaries--see section 7.7.4.1).

· A Policy for Archiving Radiology Images: A radiology image should be archived after X years and destroyed after Y years; an organizational agent, say within the regional system, could implement this automatic archiving and destruction of electronic radiology images within the organization.

· A Policy for Collecting CPR and Source Document Information on an Appointment: For each appointment the physician sees, an outpatient physician needs to find all information in the automated patient medical record related to the chief complaint. An agent is created to be executed the night before an outpatient appointment that automatically does a search through the automated patient medical record for clinical information related to the chief complaint so an index to this information can be presented to the caregiver.

· A Policy for Collecting CPR and Source Document Information on an Preadmission, Dependent Upon the Hospital Unit: A Med/Surg inpatient unit needs all chart information on the patient for the last 5 years during the inpatient stay. Previous to a scheduled inpatient admission, an agent could automatically order copies of all paper charts and retrieve automated patient medical record information from remote sites for encounters within the last 5 years.

· A Policy for Collecting Hypertension Information Set up by a Facility: Clinical research needs to be done on the effectiveness of hypertensive medications given in a facility in Bakersfield for the next half year; a facility agent could be set up to automatically record data for this research whenever a caregiver entered information on such a patient via SOAP notes.

· A Policy for Profiling a Provider at a Facility by Provider Category: A caregiver’s activities could be automatically profiled (i.e., tracked) for a group of related facilities via a facility group job category agent.

· A Policy for Organizational Security: An organization agent could control access to department-related information and specific documents. The agent could provide security against unauthorized access and disclosure, maintain the integrity of the data, and confirm the identities of the originators and requesters of the data.

· A Policy for Collecting Information on Regional Public Health: A regional agent could alert the HMO region and public health officials of usual increases in the incidence of influenza, specific bacterial infections or other public health problems.

· A Policy for Collecting Information for a Registry: A regional agent to recognize when a medical condition should be recorded to a Registry and automatically record it or inform the caregiver.

· A Policy for Collecting QA / Costing Information: An agent to inform the caregiver of lower cost equally effective procedures or medications and possible drug interactions based upon previous medications and patient medical history. The agent could also check for other quality assurance issues such as compliance with recommendations from JCAHO or other professional organizations, with state or federal regulations, or for possible duplication of orders.

7.7 Tying Everything Together to Create a Useful System for Caregivers

This section presents further requirements for an automated patient medical record system for HMO caregivers encompassing automation of manual processes in the current HMO systems (see section 4.9) and additional capabilities which implement project objectives in figure 5.8 that tie together the automated patient medical record.

The automated patient medical record system would substitute for paper patient charts, but also allow paper charts to exist: It would provide for enhanced access to patient chart information, whether automated or on paper. Additionally, it would provide other capabilities such as functions for ordering, communication between caregivers and clinical research. These capabilities are as follows:

· document patient care

· order and receive results

· display the clinical information that makes up the patient medical record

· create summary information from the patient medical record

· select clinical information and search for clinical information for display

· identify trends in the patient’s health

· identify patients of interest to a caregiver (e.g., patients in a provider’s schedule, inpatient nursing census, ED census)

· provide communication between caregivers

· incorporate healthcare organization business policies

· enable clinical research.

7.7.1 Documenting Patient Care

This section assumes the existence of a repository for source documents and repository for the Computer-based Patient Record (CPR) as described in chapter 6 and section 7.5.1.

Documents are created in the care of patients. Through these documents, vital signs, progress notes and other clinical information such as identified in section 4.4 are created and added to the patient medical record. A document for a patient can be created by a caregiver (e.g., H&P or progress notes) or can be created by transfer of information from another system to the automated patient medical record system (e.g., test results being returned from the clinical laboratory system). Before sending a completed document to the patient medical record, a caregiver must sign, or for the automated patient medical record, “electronically sign” [17], the document verifying the identity of the caregiver.

Documents can be textual, graphs, voice, video, pictures, drawings, medical images (such as x-rays or CT scans), or waveforms. Waveforms come from medical instruments and can be voluminous; thus there must be algorithms for selecting and filtering of waveform information so only the most significant waveforms would be stored on the document database. Textual documents may have embedded graphs, pictures, drawings, medical images or waveforms and may be paired with medical image or waveform documents (e.g., an x-ray and a transcription of results, an ECG and an interpretation of results).

The format of a document on the screen (e.g., an H&P SOAP note) can be very different from the equivalent printed document (see figure 7.7). For example, an on-screen document (e.g., a SOAP note) can often be combined with on-screen display and entrance of other clinical information (e.g., a list of the patient’s health problems, medication or allergies). Proposed is that there be a “document description file” that defines both screen displays of documents and printed forms of documents. The printed form can also be displayed on a screen and provide an alternate means of entrance of information recording patient examination and interview information; this printed form on the screen would ideally have the same format as a printed form that was used when the patient chart was on paper and could be used both for routine use and for times when the automated system was down. With the Source Document repository being in XML, it is appropriate for the Document Description Database to be in XSL, and a metadata description of source document data in XML Schema language (see section 6.6).

The document description for the screen would describe the document in terms of fields for display or entrance of data, while the document description for the printed form would describe the document in terms of fields as they would appear on printed forms. These fields can be as simple as displaying or allowing entrance of a patient identifier, a patient name, a patient date of birth, a provider identifier or a provider name and can be as complicated as a section for word processing that uses semi-structured elements such as provider-generated templates to facilitate entrance of information on the screen (e.g., generic text for abdominal pain in the subjective portion of a progress note).

To enable communication of information with outside organizations, documents should ideally use standardized data elements including universal patient identifiers, and industry standard provider and location identifiers, and other elements (see the Appendix for a discussion of healthcare standards). Alternatively, information in documents should at least be translatable to these standardized data elements. These same standards would also be used by registries and repositories.

In detail, the “document description” database will identify titles and other static information and will identify the following for each document field: the field type, domain, field length, font, borders, security level and screen or print location. For the screen document description, each field would be identified as display only or enterable. Additionally, for each field, the HMO data base and database data item currently containing the field data, or which will contain the field data, would be identified.

When a document is to be displayed on a screen or printed on a printer, the document description database would be used to identify how the document is structured and data from the HMO databases and data element standards file would be merged in to produce the document on the screen or printed form. Data elements that the user does not have security to view would be excluded. When data is entered for a document on the screen and the document is signed and sent, the document would be moved to the HMO data bases and data element locations for the entered fields as identified in the document description file. The document would also be stored in the document database and related to the patient encounter.

After completion of the encounter, the printed form version of the source documents during the encounter and the location of standard data elements within each document would be sent to the source document repository. The storage locations of these source documents (the identified source document repository or chart room for a paper document) would be sent to the CPR repository.

Since source documents sent to a source document repository could vary in format from one healthcare institution to another and a particular health institution might use non-standard data elements, it would be useful to have information sent along with the source document to the source document repository that translates information into standard data elements. This would facilitate interpretation by an outside healthcare institution and facilitate retrieval of the source documents based upon caregiver entered search criteria based upon standard data elements. A technique might be provided to enable users at other healthcare institutions to interpret non-standard data elements (e.g., pressing a right mouse key over a data element might show a caption with the interpreted standard data element value).

Before the encounter documents are sent to the source document repository and source document locations are sent to the CPR repository, associated patient and encounter information must first be received by both CPR and source document repositories so the document or document locations can be associated with the patient encounter. See figure 7.7. Patient and encounter information may come from systems other than the automated patient medical record system, which may be the ADT system, visit registration system, or caregiver scheduling and appointment system.

As a document is being created, CPR information, summarizing the encounter could be created. At the end of the encounter, patient and CPR information in E1384 format could be collected and sent to the CPR repository using HL7 network protocol. (What constitutes the end of an encounter and when it is the appropriate time to send encounter information to the CPR requires further study; for example, sometimes diagnostic tests connected with the encounter are not completed well after the encounter—should the transfer to the CPR wait until after these are complete?)

Many documents used during the patient care process will not provide information that is sent to the CPR repository (e.g., flowsheets during an inpatient stay). All documents that are currently part of a paper patient chart would be saved as source documents (e.g., flowsheets). Documents generated during an encounter that are not currently stored as part of a paper patient chart will not be saved as source documents (e.g., the Inpatient Clinical Summary during an inpatient stay). Nevertheless, an automated patient medical record system could provide support for all these documents.

It is also proposed that each encounter should be summarized after the encounter, either directly by the caregiver or by the system from caregiver input to documents. This is referred to as an “encounter synopsis”. The encounter synopsis would enable caregivers to quickly evaluate encounters and facilitate future caregiver finding of information in the automated patient medical record. This encounter synopsis could be sent to the CPR repository to be stored with the encounter information in the CPR repository. For healthcare organizations who have not automated the patient medical record, this encounter synopsis information could be sent to the CPR repository by e-mail and perhaps would be the only information sent to the CPR for a patient encounter.

As source documents are being entered in the HMO, techniques for facilitating input of source documentation could be used. These techniques include

· re-use of previously entered information

(e.g., patient age, height, phone number entered on one document or from data from another HMO system would be available for other documents)

· templates generated by organizations, departments or individual physicians

(e.g., templates—see figure 7.8--could be created by physicians for various chief complaints, such as for “abdominal pain”, displaying text and pick lists and areas to enter text; when interviewing the patient, the physician would pick selections from pick lists and fill in the text)

· abbreviations and symbols

(e.g., an approved set of abbreviations and symbols for Hospital XYZ for all SOAP notes, with expansion of the abbreviation or symbol upon caregiver request)

· pick lists--drop down lists

(e.g., selecting “nature” via a pointing device in figure 7.8, might display a drop down list showing “burning, sharp, dull, cramping, crushing, constant, or intermittent”.)

· documentation tailored for the patient encounter

(e.g., a nurse could use a flow sheet tailored to the patient’s diagnoses, rather then a generic one)

· automatic ordering within a clinical pathway

(e.g., a clinical pathway for prenatal care could automatically set up a series of appointments and schedule various procedures associated with prenatal care)

· entrance of information by exception

(e.g., a flow sheet allowing an inpatient nurse to record the patient’s status every hour could be structured such that the nurse would only have to input information when the patient’s condition changes).

· generation and maintenance of complete, personalized, patient care documents based upon the patient’s diagnoses, such as nursing care plans or critical path documents

(e.g., a nursing care plan generated by a program such as Davis’s Electronic Care Plan Maker [18]).

The following is an example of use of a template: A template for the subjective section of a progress note for abdominal pain might look as follows (see figure 7.8): “age yo male c/o [] pain x []. Pain is [nature], lasting []. Pain is relieved with [rfactors]; worsened with [wfactors]. Radiation []. [Denies] previous occurrence. [Denies] nausea, vomiting. States stools []. [Denies] melena, hematochezia. [Denies] use of NSAIDs. []”.

age is filled in by the system. [nature] can be defined as a multi-item pick list of values of “burning, sharp, dull, cramping, crushing, constant, and intermittent” (see figure 7.8). [rfactors] can be defined as a multi-item pick list of values of “antacids, food, and rest”. [wfactors] can be defined a multi-item pick list of values of “coffee, activity, lying down, bending, alcohol, meals, and fatty foods”.

As a physician interviews the patient and comes to the subjective section of the progress note, the physician selects the disease, (1) selecting from a pick list of body area, with abdomen picked. (2) from a pick list of organ systems with gastrointestinal picked, and (3) from a pick list of diseases dealing with the body area and organ system, with abdominal pain picked. The template for abdominal pain is shown to the physician. The physician then either fills in the blank fields of the template or selects from a pick list for a field in the template; the NEXT key goes to the next field, while the PREVIOUS key goes to the previous field. At each jump point the physician enters the following: ...(types) epigastric ... (types) 1 mo. S/p appy x 3 mos... (selects) burning, intermittent... (types) 20-30 minutes... (selects) antacids, food... (selects) coffee, bending... (types) -none... (skips)... (skips)... (types) well-formed... (skips)... (stops). The abbreviation “appy” expands to “appendectomy” upon entrance.

The resulting text would then show the following (see figure 7.9): “69 yo male c/o [epigastric] pain x [1 mo. S/p appendectomy x 3 mos]. Pain is [burning, intermittent], lasting [20-30 minutes]. Pain is relieved with [antacids, foods]; worsened with [coffee, bending]. Radiation [-none]. [] previous occurrence. [Denies] nausea, vomiting. States stools [well-formed]. [Denies] melena, hematochezia. [Denies] use of NSAIDs. []”, with the system automatically filling in the age from previous recording of birth date. When accepted (see figure 7.10), the text would display “69 yo male c/o epigastric pain x 1 mo. S/p appendectomy x 3 mos. Pain is burning, intermittent, lasting 20-30 minutes. Pain is relieved with antacids, foods; worsened with coffee, bending. Radiation -none. Previous occurrence. Denies nausea, vomiting. States stools well-formed. Denies melena, hematochezia. Denies use of NSAIDs.”.

As stated earlier in this chapter, it is the author’s opinion that when a caregiver inputs information while examining or interviewing the patient (referred to as “point of care” computing), he should use a non-intrusive computer, such as a (wireless handheld) tablet computer. Much source documentation is initially created when examining and interviewing the patient.

Use of a tablet computer while interviewing the patient would probably involve pen, rather than keyboard input. Pen input of SOAP notes on a tablet computer is facilitated by caregiver use of templates, pick lists and textual input using abbreviations. Abbreviations could later be expanded to the full text by the computer, if the caregiver so desires.

7.7.2 Medical Orders and Results

See figure 7.11. The automated patient medical record system would enable orders to be entered by a caregiver with transmission directly to the computer system of the performing ancillary department. Such ancillary departments include the clinical laboratory system, pharmacy system, radiology system and pathology system. The healthcare industry standard for an application level network protocol for sending orders between computer systems is HL7.

Results and order status changes may be returned to the ordering caregiver and other users of the automated system. The caregiver could receive an alarm for a panic result or result of a STAT order. The network protocol for return of results is also HL7.

The ordering system / ancillary system must handle simple individual orders as well as complex orders such as a single caregiver order that results in multiple orders being generated and/or an order with frequency and timing requirements or conditions. For example,

· “Give 75 milligrams of Demoral intramuscularly every 4 hours when necessary for pain”

· a single caregiver order of “Complete blood count (CBC)” might result in a series of tests being done on a blood sample in the clinical laboratory—an order based upon an “order set”: hemoglobin concentration, hematocrit, red and white counts, differential white cell count, and stained smear for red cell and platelet examination.

For complex orders such as a CBC, the ordering system might generate multiple orders from the single order (e.g., WBC, Hct, etc. from the CBC) and send them the ancillary system or alternatively a single order (e.g., CBC) could be sent over to the ancillary system and it would be interpreted by the ancillary system.

Common parameters in all orders would include (a) identity of the patient, (b) date and time order was written, (c) priority or urgency of the order (STAT, routine, rush), (d) identification of the associated encounter, and (e) electronic signature of person who wrote the order [17]. Other parameters vary according to the ancillary system. For example,

· an inpatient medication order to the pharmacy system might include (a) the identity of the drug to be administered, (b) dosage of the drug, (c) route by which the drug is to be administered. (d) time and/or frequency of administration, (e) registration number and address for a controlled substance. Types of medications orders are standing orders (carried out until the physician cancels it) and repeating orders (carried out at prescribed intervals), prn orders (as needed) or other conditional orders (based upon a condition), single (one-time) order (an order given only once) or STAT order (given immediately and only once).

· a prescription for an outpatient medication might include (a) drug name, strength and dosage, (b) the number of tablets or amount to be dispensed, (c) information to be written on the label (e.g., directions to the patient, directions for refilling and whether the drug name should be put on the label), (d) DEA registration number and address for a controlled substance, where the DEA is the Drug Enforcement Administration, a U. S. Government agency to enforce the distribution of controlled substances, (e) optional identification of the pharmacy where the medication will be dispensed (either inside or outside the HMO). (When a generic drug is ordered its name is usually in lower case, whereas brand-name drugs are capitalized.)

· a clinical laboratory test, diagnostic imaging, skin test, mycology, microbiology, EKG or other diagnostic test, an immunization, physical therapy, chemotherapy, or other therapy, might include (a) known full name or abbreviation of test or therapy, (b) optional performing area for test or therapy, (c) optional instructions, (d) optional information for scheduling test or therapy, either an appointment date, an indication that the patient will be put on a wait list or that the patient has the responsibility for dropping in for the test or therapy.

The ordering system must recognize the authority level of the caregiver and appropriately control ordering. In general,

· a physician can order any service, but needs a DEA license to authorize administration of controlled substances

· a nurse practitioner, physician assistant, registered nurse or registered respiratory therapist can order certain services in accordance with standardized procedures and protocols approved by a supervising physician

· based upon healthcare organization protocols, certain caregivers (e.g., registered nurses, physician assistants, pharmacists, respiratory therapists) may be able to enter the verbal orders of a physician, with the later co-signing of the order by the physician (e.g., within 24 hours)

· some categories of nurses are allowed to administer certain types of medications while others can not.

· a medical assistant cannot order services.

In addition to placing an order, a caregiver can suspend or restart orders, modify an order, or delete, cancel, discontinue or renew an order. Additionally, the orderer should be informed of repeating orders about to expire and upon ordering, of a possible duplicate order. Orders can be for a future date and time. For a repeating medication order, there can be a “one off order”, meaning an extra dose is given this one time. Outpatient medication prescriptions have the additional dimension of the ordering of refills.

HMO pharmacy systems include a drug compendium listing all the drugs a caregiver can order. Normally, an HMO also identifies which of these drugs it recommends, supposedly the most effective and least cost ones; these recommendations form the HMO “drug formulary”. The drug compendium may include drug costs and information for clinical checking (i.e., drug interaction checking). Such a drug compendium/ formulary could be made available or be duplicated for the automated patient medical record / order entry system. For medication orders, either the ordering system or the pharmacy system could do immediate clinical checking of the order along with other stored patient clinical information, including checking of drug/allergy, drug/drug, drug/food and drug/laboratory interactions. Such clinical checking could be done by the computer while the caregiver is entering the order. The ordered drug could be checked as being in the HMO formulary, with the system informing the caregiver if it isn’t and suggesting alternative less costly or more effective drugs.

When its discovered that a patient is allergic to a medication, this allergy should be entered either into the pharmacy system or automated patient medical record and transferred to the other. Also, the medication allergy should be sent to the CPR and national or international databases without the patient identifier, perhaps with additional information describing the patient (e.g., sex, age, health problems, etc.).

Some allergies may not be clear cut--for example, a patient may be allergic to a medication but the patient may still want to use it because the benefit exceeds the side effects (e.g., Prednisone for severe asthma), some allergies occur inconsistently, for example, only when the patient takes the medication over a long period of time, and some allergies are assumed to be allergies and are not yet confirmed. Such not so clear cut allergies will be referred to as “ambiguous allergies”. An ambiguous allergy should be recorded also for a patient and identified as such, recording the reason for the ambiguity.

The Controlled Substances Act of 1970 puts special restrictions on the ordering and dispensing of certain drugs, including narcotics, some stimulants and depressants, hallucinogens and steroids, and of chemicals used in the illicit production of controlled substances. Controlled substances are divided into five classes called schedule I through schedule V. Schedule I drugs are experimental and can be dispensed by a very limited number of institutions or are drugs that, on an emergency or temporary basis, have been determined to pose an imminent hazard to the public safety. Prescriptions for schedule II drugs must be written and may not be refilled; schedule II drugs have a “high potential of abuse” [19]. Prescriptions for schedule III and IV drugs may be written or oral but may only be refilled up to five times within 6 months; schedule III drugs have “some potential for abuse” while schedule IV drugs have a “low potential for abuse” [19]. Schedule V drugs are less restricted but can be dispensed only to patients at least 18 years old; a patient must offer identification and have his or her name entered into a log maintained by the pharmacist; schedule V drugs may be “subject to state and local regulation” [19]. Schedule I drugs include street drugs of no medical use (e.g., heroin, LSD and marijuana currently); schedule II drugs include street drugs of some medical use (e.g., cocaine, methamphetamine) [20]. Physicians who order controlled substances must have a DEA number.

The FDA also rates drugs as to their risk in being used during pregnancy [19]. Categories of such drugs are category A, “controlled studies show no risk”; category B, “no evidence of risk in humans”; category C, “risk cannot be ruled out”; category D, “positive evidence of risk”; and category X, “contraindicated in pregnancy”.

Dietary orders could also do clinical checking for drug/food interactions. Clinical laboratory orders could also check for drug/laboratory interactions.

The HMO clinical laboratory system would include a test directory used to validate laboratory test requisitions, containing information such as test name, test measurement units, and normal reference range and low and high crisis (panic) values that may be calibrated for a specific clinical instrument. The automated patient medical record / order entry system needs the same information for clinical laboratory order validation and to provide information to the ordering caregiver, especially when the results are out of range. Other ancillary systems require additional test directories available to the ordering system for order checking.

Ordering of certain urinary and blood clinical laboratory tests for street drugs (e.g., cocaine, heroin and marijuana), alcohol and HIV (for AIDS), and view of their results may be controlled by health care organization policies, regulatory commission regulations, and federal and state laws.

Upon entrance of a STAT order, the ordering system, if possible, should check to see if the clinical system receiving the order is up and network connections are up. If not, the caregiver could be informed so he/she could consider taking alternative actions in getting the order through (e.g., through telephone communication with the clinical laboratory).

Once an order is input by the ordering caregiver, then the ancillary system or ordering system could assist other caregivers in the performance of the order. For example, a clinical laboratory or other diagnostic test system could print out test preparation instructions for the technician or nurse to execute the test (e.g., take a blood specimen), precautions, normal test values and crisis values, implications of results and post-test care. A pharmacy system could automatically record inpatient medications that were ordered on an automated MAR (Medication Administration Record) within the unit where the patient is located so a unit nurse could record on the system when the medication was administered. Calculations could be done to assist in the performance of an order, for example, body surface area calculations to determine the proper dosage of a medication.

Ancillary departments that perform tests or handle changes in order status, could record and return the result or order status back to the automated patient medical record / caregiver ordering system. HL7 also is the standard applications level network protocol for this.

In order to enable the automated patient medical record system to match up the order with the performing system and to match up returning results or order status with the original order, HL7 provides match up mechanisms. When an order is created, the automated patient medical record system / order system (the system placing the order) adds a placer application identifier to the order identifying the automated patient medical record system / order system as the system through which the order was placed; a unique placer order number is also assigned to the order to uniquely identify the order within the system placing the order. Along with the order would also be an identifier of the system filling the order (e.g., the clinical laboratory system, the pharmacy system); this filler application identifier would be used to route the order to the correct performing application system. The placer application identifier would be used by the system filling the order to determine the system to which results or order status should be sent; once the result or order status is received by the ordering system, the placer order number would be used to match up the returned results with the original order.

Results could be identified as normal, abnormal, or panic (crisis) value by the ancillary system. The ordering system could periodically check for returning results and alarm the caregiver of an abnormal or panic value result or of a result for a STAT order. As part of the order, the ordering caregiver could identify the conditions under which he would be alarmed (e.g., for a patient with a known condition, the caregiver could include a larger reference range so the caregiver would not be alarmed when the test result is abnormal but an expected value, or, on the other hand, the caregiver could indicate to be alarmed when a particular set of results come back, independent of their values). Normal ranges could be based upon age and race. Caregiver teams for the ordering caregiver could be set up so that a caregiver in that team could be notified of the alarm if the ordering caregiver is unavailable.

Order statuses would also be returned. Order statuses might include the following: open statuses (order held or suspended with resume criteria, order scheduled, specimen collected, specimen received, service performed, results transcribed, medication dispensed, medication administered), historical statuses (order completed, canceled or discontinued).

Where the ancillary department is not yet automated, then orders and results could be communicated to the ancillary department via e-mail and put on a work list. Results could be returned via e-mail for storage with the automated patient medical record.

In some cases there can be orders coming from the ancillary system, bypassing the ordering system (e.g., lab requisitions and results initiated through the clinical laboratory system). Some clinical laboratory systems automatically generate an order if a test is out of range, usually to verify that the result is actual rather than due to equipment problems; this is referred to as “reflex testing”.

When an order is made within the automated patient medical record system by a caregiver, the order must be tied to the associated encounter so it can be associated with the encounter within the automated patient medical record. If the system cannot accurately identify the encounter, then the system might have to request the caregiver to select the encounter from a pick list of encounters. When the order originates outside the automated system (e.g., a “reflex order”) information from the ancillary system might have to be passed to the automated patient medical record system to identify the encounter.

Before sending an order to an ancillary department or performing area and recording it on the automated patient medical record, a caregiver must “electronically sign” the document verifying the identity of the caregiver. At that point, the system could verify that the caregiver has the authority to make the order.

Some results of tests or other orders require interpretation by experts, producing diagnostic findings. Diagnostic images may require interpretation by radiologists. Anatomic pathology specimens require interpretation by specialized experts, as do pulmonary function tests to test respiratory function.

Anatomic pathology deals with wet specimens, tissues, anything out of the body (a piece of bone, skin tissue, muscle, blood vessel, bullet). Anatomic pathology includes surgical pathology, cytology (study of cells), histology (microscopic structure of tissues) and autopsy (multiple body parts). Cytology deals with smears: vaginal, sputum, semen--fluids with cellular material.

An addendum is an appendage to an existing diagnostic finding document that contains supplemental information. The parent document remains in place and its content is altered by the addendum. For example, a clarification or correction to a diagnostic finding for an anatomic pathology specimen might produce an addendum.

An addendum could occur after any order is complete to amend the order, results or diagnostic findings. Once received, this must be stored with the original order.

Once an order is completed and results or diagnostic findings are returned or once an addendum is returned, this information should be sent to the HMO CPR database for transmission along with the encounter documentation to the CPR repository. Orders, results, diagnostic findings and addendums could also be sent to the HMO source document database for transmission to the source document repository. See figure 7.7. Ideally, these transmissions should occur after all encounter documentation has been completed and after all associated orders, results, interpretations and addendums are complete, so a complete description of the encounter would be available.

7.7.3 Communication Between Caregivers and Patients

Patient medical record documentation is the primary way for one caregiver to communicate clinical information about a patient to a future caregiver seeing the patient. Word of mouth is the primary method for communication between caregivers currently seeing the patient, whether this communication is face to face, on the telephone or over pager or a loud speaker. Electronic communication, e-mail, and more generally “messaging”, is becoming a more and more important method of communication between caregivers.

E-mail from one caregiver to another or other caregivers can be formatted and non-formatted messages with optional saving of the e-mail in the automated patient medical record. Types of e-mail include the following: (1) formal memos between caregivers, (2) communication of patient phone messages from one caregiver, especially an advice nurse, to a physician, and responses from the physician to the originating caregiver, (3) communication of patient requests of drug refills from an automated drug refill phone system to the ordering caregiver or to a surrogate, (4) when there is no other direct on-line connection between the ordering system and an ancillary system associated with a diagnostic test, communication of the order to a performing area, with possible display of orders on a performing area work list, and optional communication of results back to the ordering caregiver, and (5) for small healthcare institutions, communication of a summary of a patient encounter for storage in the CPR, which might have to substitute for the more detailed CPR information that could be provided by a larger healthcare institution.

Electronic communication here will be separated out into two systems: standard e-mail and caregiver messaging. Beyond normal e-mail capabilities, there should be a capability to (1) associate an e-mail with a patient and (2) optionally include it in the patient medical record.

A caregiver messaging system to allow communication between caregivers for care of the patient should have additional capabilities beyond e-mail, including the ability to identify a patient and optionally include the message in the patient medical record. Usually such phone calls originate as a result of phone calls from patients to one caregiver (often an advice nurse), with the message going to another caregiver (usually a physician), with a response coming back to the originating caregiver and/or to the patient. The following are some capabilities suggested:

· enable messages required by the HMO to be pre-formatted with a “fill-in the blanks” capability

· enable a forwarding capability that enables (1) the first caregiver (e.g., an advice nurse or appointment clerk) to send the message, (2) a receiving caregiver to receive and respond to the message, optionally sending it to the originating or another caregiver to convey the information to the patient

· enable the receiving caregiver or the caregiver responding to the patient to “close out” the message, indicating it has be taken care of

· enable assignment of an “importance level” that a receiving or responding caregiver could use to determine what messages to handle first; this importance level could be associated with a “close out time period” (e.g., must be closed out within 2 hours)

· enable identification to the initiating caregiver, receiving caregiver or responding caregiver of messages that have been closed out and that have not; enable identification of messages that are past due or are close to reaching the end of the close out period

· enable association of a care team with a receiving caregiver or with a responding caregiver to receive the message if it is not handled within a given period of time

· enable the care team to redirect messages to other receiving or responding caregivers when the referenced one is not available; enable the setting up of system controlled redirection based upon the unavailability of the caregiver, e.g., based upon the dates and times the caregiver is out-of-clinic or on vacation, perhaps based upon the caregiver’s schedule

· enable the initial and responding caregivers to document their conversations with the patient

· keep a telephone call history of telephone calls, especially from patients, that initiate message, and an audit trail for the subsequent messages to the various caregivers and care teams

· keep messages, orders and results, and e-mails in an “in-box” for later retrieval, either for a particular caregiver, a care team, or a nursing unit

· enable display of a message, order, order and result and/or addendum, order pending a result, or e-mail upon selection from the in-box

· upon selection of a message for a patient from an “in-box”, enable the associated patient medical record to be retrieved

· enable messages to be recorded in the patient medical record along with documentation for encounters and telephone calls with the patient

· enable reminder and to-do messages for a caregiver to send to himself at a later date or time

· support unified messaging, allowing messages to be text, fax, voice, graphics, picture, Internet page, or video, or any combination of these by embedding non-text within the text or linking to an item within the text

· enable an alert message to be set up for a patient to be brought up upon the patient’s phone call or elsewhere in connection with patient demographics

· enable sorting or filtering of messages by type, importance level, recipient,.

Telephone communication to caregivers from patients can be supported by computer telephony integration (CTI), computer supported directing of calls. This enables telephone calls from patients to an HMO to be directed to a category of caregivers (e.g., an advice nurse for advice or an appointment clerk for an appointment). Other communication could be re-fill requests sent to the pharmacy or to the appropriate physician.

The standard methodology [21] to exchange messages between originators and recipients is X.400 external to the Internet; this standard is implemented globally. The standard methodology for e-mail within the Internet is RPC 832 or Simple Mail Transport Protocol (SMTP). Commercial e-mail and other messaging systems generally use these standards.

Another form of communication between caregivers, which does not involve e-mail or messaging, is recording of alerts (more urgent) and reminders (less urgent) identifying notification messages describing patients put in by one caregiver to later inform other caregivers. These alerts and reminders might be recorded permanently or could be in effect only for a defined time period. These may be allergies, notification of sight, hearing, speech or mobility impairment, notification of problems such as violent patient or of drug concerns, notification of existence of advance directives, or notification that a patient who calls in should be transferred over to a particular provider. These alerts and reminders should be shown to caregivers based upon their security and “need to know”.

E-mails from patients should also be supported, with the same capabilities as CTI. For example, a patient might send an e-mail with a health question to an advice nurse that could be answered by any available advice nurse. A re-fill request could be automatically send to the pharmacy or the appropriate physician. Such e-mails are most easily handled through the Internet, which would tack on the correct recipient, rather than having a patient do this him or herself.

7.7.4 Proposed Summarizations

The current paper patient chart is patient centered and is composed of the documents such as is listed in section 4.4.3. It is proposed that an automated patient medical record, besides including the same information and additional information suggested in this chapter, also include summarizations of information in the patient’s medical record that could be derived either automatically by the system from the information in the documents or by additional input by caregivers:

· patient clinical summaries

· past encounter synopses

· encounter document lists.

This information summarizes or indexes information in the patient medical record.

7.7.4.1 Clinical Summaries

A “patient clinical summary” could be generated from patient medical record document information (e.g., medications prescribed from medication orders) together with additional information added by caregivers (e.g., medications currently being taken, whether prescribed or over the counter). It is suggested that there be two categories of patient clinical summaries:

· overall clinical summary

· inpatient clinical summary, available during the current inpatient stay only.

For all patients there would be an overall patient clinical summary that could consist of any of the elements in the summary information in the CPR repository. This overall clinical summary could, for example, follow the ASTM E1384-96 standard for the CPR and contain the information listed in section 7.5.1. On the computer screen, the overall patient clinical summary could be tailored for the caregiver.

Selection of a data element from the screen could drill down to other patient medical record information, For example, one aspect of an overall patient clinical summary could be a list of significant health problems; upon selection of a problem, associated summary information would be displayed, such as encounters dealing with that problem.

The ideal patient clinical summary would consist of data elements available in national CPR repositories that follow strict data standards. This would enable the clinical summary to display patient clinical information from outside healthcare institutions as well as from the HMO. A capability to translate the national standard data elements to local data elements might be accomplished by a caption produced by right clicking a pointer device over a national standard data element (e.g., clicking a universal patient identifier might display the local identifier of the patient, such as a medical record number)--this would be the reverse of a source document from the source document repository that would be stored in the format of a healthcare organization and where right clicking a data element might display the data in the format of a national standard data element.

For inpatient stays, there could be an inpatient clinical summary that is similar to the Kardex, that is generated at the start of the inpatient stay based upon patient medical record information and disappears after discharge; for possible information in such an Inpatient Clinical Summary, see section 4.4.3.2.

For the example overall patient clinical summary in this book (see figure 6.3), we will present a overall patient clinical summary consisting of the following information:

· shortened patient demographics

· a list of encounters (inpatient stays, outpatient clinical visits, ED visits, phone call encounters, surgeries), including diagnoses

· a list of significant health problems / current medical conditions / concerns as entered and updated by healthcare practitioners

· a list of risk factors for diseases

· a list of medications ordered and dispensed through pharmacy systems

· a list of those medications that the patient currently takes. This would include all prescribed, over-the-counter and herbal medications currently being taken by the patient. (Clearly this list is more pertinent to the patient’s current health than the previous list.)

· a list of clinical orders and results, including all procedures for the patient

· a list of allergies and adverse reactions, as recorded in ancillary systems, such as the pharmacy system. Note that some allergies may not be clear cut allergies--for example, a patient may be allergic to a medication but the patient may still want to use it because the benefit exceeds the side effects (e.g., Prednisone for sever asthma), some allergies occur inconsistently, for example, only when the patient takes the medication over a long period of time, and some allergies are assumed to be allergies and are not yet confirmed. Such allergies will be referred to as “ambiguous allergies”.

· a list of allergies and adverse reactions as recorded and updated by healthcare practitioners (“Ambiguous allergies” may be identified as such.)

· a list of immunizations, skin tests and reactions, recorded by the immunization system with updates by the healthcare practitioners

· a list of appointments

· a list of assigned caregivers, including any assigned principal primary care provider and case manager, if any

· active cases

· referrals

· active critical pathway documents / trend documents

· alerts and reminders (e.g., violent patient, court injunction against patient, drug seeking behavior)

· a picture of the patient--This may be important to insure against fraudulent use of an HMO identification card and resultant inaccuracy of information in the patient’s medical history.

The information in a clinical summary would come either from other clinical systems or through other parts of the automated patient medical record system (e.g., through orders, progress notes, etc.) An exception to this is the list of current medications that should be updated through the overall clinical summary whenever possible through caregiver interviews of the patient or other sources. Also allergies and significant health problems should be enterable through the overall clinical summary.

Often the patient clinical summary information would be enough to give a caregiver a good overall picture of the patient’s health without the need for the caregiver to look further at documents in the patient medical record.

7.7.4.2 Past Encounter Synopses

What would greatly assist a caregiver in identifying what happened during a particular encounter, in the process of evaluating encounters of interest, would be a synopsis of each encounter. This synopsis could be specifically created by a caregiver after an encounter or it could potentially be generated by the automated system automatically after an encounter. Perhaps the HMO could require that a synopsis be created for every encounter. A caregiver might then, for example, ask to select all encounters related to urinary incontinence and get the synopsis of each such encounter.

7.7.4.3 Encounter Document List

Selection of an encounter from the patient clinical summary would list all documents for the encounter. From a document list, a caregiver could select and display the document. Also upon caregiver request, the automated patient medical record system could list all documents for the patient.

7.7.5 Identifying Patients

Although the automated patient medical record is patient-oriented, each caregiver works with many patients. Therefore each caregiver needs a list of patients he or she is caring for and a way to select a particular patient from such a “patient list”, without having to specifically enter a patient identifier.

The list of patients required by a caregiver depends upon the job category and location of the caregiver. Patient lists could include the following:

· Inpatient List (or Unit Census) that shows all admitted patients in a nursing unit

· Inpatient Physician List that lists all admissions for which a physician is either the attending or admitting physician, a consultant or attending resident.

· Outpatient List (or Schedule) that consists of a complete schedule for a caregiver in all outpatient clinics he/she works in for a particular date in a healthcare organization. Each patient with an appointment or registration in the healthcare organization is shown along with the type of appointment or registration. Other times where there is no appointment or registration are identified as to purpose and may be (1) time where the caregiver is outside outpatient clinics or outside the healthcare organization, (2) time where the caregiver can see patients but where patients normally cannot be appointed (e.g., a drop-in clinic) and (3) time where a patient can be appointed but there is no appointment yet. Other times identified independent of whether there are appointments and registrations or not are the following: time that is in transition from appointment to non-appointment time whose future purpose is identified and either (1) current appointments are kept or (2) current appointments are canceled.

· Emergency Department List that includes all patients registered in the Emergency Department.

· An Outpatient Clinic, Inpatient Unit or Emergency Department Room Map that is a diagram of all rooms in an outpatient clinic, in an inpatient unit or in the ED that identifies the patient, if any, currently in the room and the room status. Room statuses can be “room to be cleaned,” “room available”, “patient in room”, “patient ready to see nurse”, “patient ready to see physician”, “patient seeing physician” and/or “patient seeing nurse”. When the room is to be cleaned, housekeeping could be notified and when the patient enters the room, a caregiver may be notified. Note that the outpatient clinic room map is also the easiest mechanism for identifying the end of a patient outpatient visit, when the patient is identified as leaving the room. Physicians and nurses could wear electronic trackers that could identify the rooms they are in. (Combined with the time of a visit registration, room status and time of room status change can be used to measure waiting times in the wait room and time to see various caregivers.)

· Surgery List listing surgeries for the attending caregivers (primary surgeon, assisting surgeon, co-surgeon, consulting surgeon, anesthesiologist, nurse anesthetist, or nurse midwife).

· Patient Panel for a particular caregiver that lists all patients for whom the caregiver is an assigned physician or nurse practitioner.

· Work List that lists for an ancillary department patients having orders to performed by the ancillary department (e.g., blood to be collected), together with details on the order, where an ancillary department is a department providing services for patients or for other medical department providing direct patient care.

· Caregiver-defined Patient List that is a list created by a caregiver from selecting patients from other Patient Lists. A caregiver may “attach” a label to a Caregiver-defined Patient List. Caregiver-defined Patient Lists may be date oriented or not.

Selection of a patient on a patient list would identify the patient and might drill down to clinical information for the patient, for example, to patient demographics, a patient clinical summary or the document list. Alternatively, the patient identifier could be entered to individually identify the patient, with optional drill down to the patient clinical information.

An Inpatient List (or Unit Census) or Unit Map could be used by inpatient nurses and unit assistants; the automated system might provide a means to interface with other systems to assign nurses with patients, taking into account patient acuity. The automated system might use past visit information and factors such as age and sex to predict how often patients are likely to come in for an outpatient visits in the next year and use this information to equitably assign patients to caregivers’ patient panels; for example, assignment of a healthy teenager to a caregiver’s panel is certainly not equivalent to assigning an octogenarian.

A Unit Census and Inpatient Physician List could be used by inpatient physicians. An Outpatient List (Schedule) and Clinic Room Map could be used by outpatient physicians, outpatient nurses, in-clinic medical assistants and advice nurses.

An Emergency Department List and an Emergency Department Room Map could be used ED physicians and nurses, including triage nurses. Surgery Lists could be used by all caregivers involved in surgeries.

In general, patient lists can be created automatically by the automated patient medical record system from encounter and related information sent to it by other clinical systems (e.g., from the ADT system, outpatient scheduling system, registration system, etc.) In some cases, however, the automated patient medical record system might have to initiate an encounter or an encounter status change itself because the automated patient medical record system might learn about the encounter or encounter status change ahead of the clinical system: For example, adding a patient to an Inpatient List or Inpatient Unit Room Map is a possible way to do a “quick admission”, with the sending of information on the admission to the ADT system so the admission could be completed by the ADT system. Removing a patient from a room in an Outpatient Room Map could be used as a way to identify the end of an outpatient encounter, which otherwise could not be known.

A Caregiver-defined Patient List, created by selecting patients off other lists or by individually identified patients, could be used by physicians, nurses, advice nurses and all other caregivers.

A capability to allow caregiver input of a patient identifier to identify the patient should, of course, be provided.

When a patient does not have identification with his patient identifier and is not on a patient list, then it is useful to have a search by patient name to find the patient identifier. The telephone number, address, sex and date of birth can then be used to verify that the patient information found indeed belongs to the patient. In the healthcare industry, a common search is a “Soundex Search”. The user enters the first and last names of the patient, sometimes the sex and birth year. The system comes back with all possible matches, including the telephone number, address, sex and date of birth to determine the correct selection, and the patient identifier.

7.7.6 Organization, Selection and Information Retrieval

In order for a caregiver to find clinical information of interest for a given patient, the system should be able to

· organize clinical information so that the information of interest to a particular caregiver can be easily found

· select clinical information based upon previously established relationships of information

· find clinical information where there are no previously established relationships of information.

The automated patient medical record could be organized so that information could be easily found by a caregiver. Through established relationships on the database, a selected item of information should be able to be used to select related clinical information (e.g., selection of a significant health problem on the overall clinical summary could select synopses of all encounters associated with that problem, or selection of a patient encounter on an overall clinical summary could be used to select a document list of all documents for the encounter). Searches for information could be done where there are no clearly established relationships (e.g., to search for all encounters that have documents with words related to the respiratory system).

Organization

The automated patient medical record could be organized so that information could be easily found by a caregiver. This organization could include summaries of clinical information. And this organization could include categorization of clinical information such as putting it into categories relevant to a caregiver. This organization of information could be tailored for a particular type of caregiver.

Examples of summaries are the “overall clinical summary”, summarizing all patient clinical information and the “inpatient clinical summary”, summarizing clinical information about an inpatient. An example of categorization is creating chart tabs categorizing the patient medical record into categories relevant to the caregiver (e.g., chart tabs for various medication related documents displayed when a pharmacist views the patient medical record).

Selection

Possible relationships that could be set up during the creation of the automated patient medical record that could later be used for selection--where selection of the first item goes to the related item--are shown in figures 7.12, 7.13, and 7.14. Figure 7.12 identifies possible relationships between a patient’s problems and other elements in an automated patient medical record. Figure 7.13 identifies possible relationships between the patient and elements in the automated patient medical record. Figure 7.14 identifies possible relationships between items in the overall patient clinical summary and other clinical information in the automated patient medical record.

(With previous generation non-relational databases, such relationships were stored as pointers. With relational database systems, such relationships are generally established by having common data within associated tables, although, for efficiency, some of these relationships result in indices being created also.)

Proposed relationships between a patient significant health problem, condition or concern and other elements in the patient’s automated patient medical record are described in figure 7.12. Establishing such relationships requires an effort from caregivers, but is worth the effort because it enables a caregiver to quickly find clinical information on the patient dealing with a specific problem. After or during an encounter, a caregiver could associate the encounter with one or more problems; this association is required for the ASTM E1384 version of the CPR repository and source document repositories according to my conceptions of them. Based upon a specific problem, the caregiver could set up a clinical pathway of clinical practice guidelines identifying patient care to be given, possibly across multiple encounters (e.g., for a pregnancy, from pre-natal care through the birth of the baby). With a suspected problem (a concern) the caregiver could identify an associated trend document to automatically track an item that measures the concern (e.g., a growth chart or a blood pressure / cholesterol graph over time). Later, the caregiver could select for display the encounters associated with a particular problem; the caregiver could also identify that a clinical pathway, trend document or follow-up message is associated with a particular problem.

When a provider defines a defined outcome case to track a treatment, a caregiver must associate the defined outcome case with a problem. Associated with the defined outcome case, in addition to a treatment plan and notes, could be a clinical pathway or clinical practice guidelines to define the treatment plan or a trend document.

Proposed relationships between the patient and the elements I propose to be part of an automated patient medical record appear in figure 7.13---Such selections could be used to quickly drill down to clinical information that is most useful to the caregiver user. After selecting the patient by entrance of an patient identifier or selection of the patient from a list of patients (a patient list), the caregiver user could select to display any of the following:

· patient demographics

· overall clinical summary

· inpatient clinical summary

· complete document list, from most to least recent

· encounter synopses list, from most to least recent

· current clinical pathways / trend documents

· current defined outcome cases, chronic care management cases or patient cases

· current alarms / alerts.

Figure 7.14 identifies possible relationships between items in an overall patient clinical summary and other clinical information. For example, a medication displayed on the overall clinical summary could be used to pick up a synopsis of the encounter where the medication was first prescribed.

Information Retrieval and Searching

Information retrieval is a field of computer science that deals with the automated storage, searching through, and retrieval of textual documents. Textual documents can either be structured so searching and retrieval is very quick or it can remain unstructured, in which case searching and retrieval is slower.

References [22] and [23] respectively discuss information retrieval in general and information retrieval in healthcare. The book Information Retrieval: A Health Care Perspective [23] covers both patient specific searching, as discussed here, but also knowledge-based searching (e.g., medical research journals, summaries of medical information, etc.)

Searches can be done to find all encounters with a particular diagnosis or chief complaint, picking up associated documents, can be done for particular clinical tests with a specified range of values for results, etc. Searches can be done within one database or across many distributed databases, possibly in different healthcare organizations, in CPR repositories and source document repositories (i.e., throughout the Patient Health Record). Searching can be done by searching for particular data values in identified fields, by searching text that is pre-indexed or by searching through the words in free text, where “free text” is unstructured, uncoded, text.

Two words describe the ideal search: “precision” and “recall”. “Precision” means retrieving only exactly what you need, limiting the number of items retrieved. “Recall” means retrieving everything you need, possibly broadening the number of items you retrieve. Clearly these two concepts can be at odds with each other.

Within the automated patient medical record and the Patient Health Record may be the following types of fields that can be searched:

· fields (ideally using national standards) with a small number of possible values (e.g., male, female, unknown for sex)

· fields with numeric information (e.g., the results of a clinical laboratory test)

· fields with a very large, but finite, number of values (e.g., ICD-9 diagnosis codes)

· free text fields (e.g., SOAP notes).

For fields with a small number of values, searches for exact matches are useful (e.g., find “myocardial infarction”). For fields with numeric values, searches using numeric conditions are useful (find “urine calcium > 275 mg/24 hours”).

As far as searching for clinical information within fields with a large number of values or within free text is concerned, I think there are two other types of searching that are useful. One type of searching is to search for exact matches but to also search for all synonyms (e.g., a search for “myocardial infarction” would also find occurrences of “heart attack”). Because this type of searching excludes searching for related items that are not matches, I will refer to it as exclusive searching.

A second type of searching that I think is useful for free text and fields with a large number of values is to search for exact matches and synonyms but also to search also for related clinical information. Say any exact match or synonym is given a “match” value, m, of 1.00, but when related information is found, then a partial match is found with a “match” value of less than 1.00, identifying how close the match is.

Consider figure 7.15. Say the user searches for “BPH” in encounter documents. If “enlarged prostate”, “prostate hypertrophy”, “benign prostatic hypertrophy”, “BPH”, or a disease code such as an ICD-9 code for this disease, 222.2, is found in a document, then the document contains a perfect match with m=1.00. If “prostate” or “prostatis” is found in a document then the document contains a partial match with m being high but less than 1.00. If “urogenital” is found in a document, then m might be a low value indicating a partial match that is less specific. Perhaps a document with “bladder” in it might get an m greater than 0 but an even lower value.

Such a search, I will refer to as inclusive searching, because it includes searching for related items. Reference [24] identifies one information retrieval algorithm that identifies how to do an “inclusive search”. This approach falls under the category of “thesaurus construction” discussed in reference [22]. Whether existing medical thesauruses such as UMLS can be used for inclusive searching needs to be studied; see the Appendix for more information on UMLS.

Whether using an exact match, numeric condition, exclusive or inclusive search, searching in the automated patient medical record system could be described as follows: “Search through field W in item X for strings Y, selecting Z where strings Y is found”. For example, field W might be SOAP notes fields, item X might be encounter documents and Z might be encounters. Y might be a single string or some logical combination of strings, using logical operations; for example, search documents for “urinary infection” or “bladder infection”, or search documents for “pain” and not “denies pain”.

Searching through multiple fields within multiple items to select items, such as encounters, is also possible. Such complex searches if done over and over again are better done through agents (see section 7.6), set up previously, than for ad hoc searches. For example, an agent could be set up that runs the day before the appointment to search the automated patient medical record for items related to the chief complaint, producing a problem-oriented patient clinical summary.

With the popularity of the Internet, many companies use information retrieval from many different Web sites on the Internet based upon user entered free-form text (e.g., Yahoo [25], Google [26], etc.). Expertise from these companies might be used for methods to search through the Patient Health Record. Reference [27] describes how many of these “search engines” work.

Feature Analysis, Extraction and Selection

One form of information retrieval is analysis of images and waveforms for “features” selecting them based upon the existence of these features. Diagnostic images, waveform information (e.g., EKGs) and other graphic or image information should be in a form where, in the future, they can be analyzed by an automated system to do automated diagnostic interpretation and thus assist caregivers in doing clinical interpretation of these images and graphics. Additionally, the automated system should provide support to caregivers in selecting information from monitoring systems (e.g., ICU, Guardian Angel systems) for inclusion in the automated patient medical record, as usually such information is too voluminous to store permanently in the patient medical record. These are forms of feature analysis and extraction that could supplement an automated patient medical record system.

7.7.7 Medical References

Medical references would be available on the Internet and via CD and hard disk storage on a computer. Currently available and suggested new medical references would include the following:

· medical information on the Internet

· MEDLINE, medical databases that include information from various medical journals produced by the National Library of Medicine.

· Micromedex , reference libraries produced by the Denver-based MICROMEDEX, Inc., with comprehensive reference libraries for toxicology, pharmacology (including drug interactions), emergency and acute care, occupational medicine, chemical safety, and industrial regulatory compliance

· on-line PDR (Physicians’ Desk Reference) or equivalent, providing physicians with information on prescription drugs

· Local healthcare organization databases including the healthcare organization drug formulary, DME (durable medical equipment, such as wheelchairs, crutches, etc.) formulary, policy and procedure manuals, clinical practice guidelines and protocols, best practice alternatives.

An appropriate mechanism to display such textual material is the Internet or a locally created or enterprise wide “Intranet” or multiple healthcare organization “Extranet”. Such documents could also include hyperlinks to other documents and include pictures, graphs, Java programs, spreadsheets, movies, sounds and any other images that can be contained on a computer file. Documents can be viewed by browsers such as Netscape Navigator or Microsoft Explorer.

Enterprise-wide on-line, rather than paper, documentation is becoming an increasingly important part of many major businesses, as is evidenced by the many companies going into the on-line documentation business, including Lotus (with their “Domino” system) and newer companies such as Documentum. Such documentation is largely handled through Intranets. These documentation systems enable enterprise wide creation, controlled access, review and update, routing and management of documents [28,29]. A current ISO standard (ISO 8879:1986) for such documents is SGML (Standardized Generalized Markup Language) [30]--The language used to create web sites on the Internet, HTML (Hypertext Markup Language) [31], was created by taking a subset of SGML.

An emerging standard for enterprise-wide documentation on the Internet is XML, which is also a subset of SGML. XML is a language with many more features than HTML, but is much less complex than SGML, and is thus a compromise between HTML and SGML [32]. A standards body that controls both the structure of HTML and XML on the Internet is the World Wide Web Consortium (W3C) [33].

Enterprise wide policy and procedure manuals, clinical practice guidelines and protocols could be created, controlled and distributed via an Intranet using XML, SGML or HTML. XML, HTML and SGML are languages of “tags” used to format text. Tags usually come in sets, such as <B> ahead of the text and </B> after the text in order to bold the text on the screen. Tags are used to structure the text (e.g., define headings); for presentation formatting (e.g., to define the fonts); for links to other document pages often at other completely independent sites; for graphics, dividers, backgrounds and colors, special characters, forms and tables within the text; for initiation of JAVA programs within the text (e.g., to retrieve information from data bases or for sound and animations); and for common gateway interface (CGI) processing (e.g., to present forms to net users and allow users to send them back). XML and SGML differ from HTML in that tags can be “defined on the fly”; at the start of the program, a tag can be defined and then used later in the program.

Web servers handle requests from browsers on PCs to produce web pages for the PC users. CGI is a standard for passing a web user’s request to an application program and to receive data back to forward to the user; CGI could consist of C++, Perl, Visual Basic or other languages. Through CGI and Java, web servers could potentially be used along with SGML, XML or HTML to create web pages as part of an automated patient medical system. The appropriateness of this use of Java, CGI and SGML, XML, or HTML over an Internet, Intranet or Extranet is explored in section 12.2.3. An alternative to CGI or Java are Active Server Pages (ASPs) or Java Server Pages (JSPs), which embed scripts in web pages with a script executed in the web server before the page is sent back for display. CGI, Java, ASPs and JSPs all add dynamic content to web pages. CGI and Java can be used to update databases with data from the user.

Medical references of any source--on the Intranet, a CD, or company database, or as part of the automated patient medical record--require powerful information retrieval capabilities to find the appropriate document or information. Again see references [22,23].

7.7.8 Supporting Clinical Research

Supporting clinical research entails three parts:

· searching for candidate patients to participate in the clinical research

· recording results of the research with selected patients who agree to participate

· recording the results of research while protecting the identify of patients and providers.

Searching for candidate patients would involve the searching techniques of section 7.7.6, but where what is being searched for are patients with certain characteristics. For example, for research on a drug for a particular medical condition, ideal candidates for such research may be patients with the targeted medical condition and no others and who do not take other drugs conflicting with the targeted drug.

Agents could be used to collect clinical research information on-line for patients as care is being given, or alternatively, information could be collected afterward from the patient medical record after it is complete. Research could potentially be done anonymously, with the identity of the patient removed, which would potentially allow research to be done without the consent of the patients. Identities of providers could also be removed.

When clinical research is done with many patients, then it is much easier for a system or caregiver to do searches on encoded information rather than textual information. For example, a caregiver can search patient medical records for patients with cardiovascular disease by searching for instances of words associated with cardiovascular disease, but the caregiver would have to do some additional analysis of the clinical information to determine if the patient did indeed have cardiovascular disease or just have symptoms of the disease. On the other hand, if patient diagnoses were encoded (e.g., into ICD-9 codes), then patients who have cardiovascular disease could be found with certainty by searching for all ICD-9 codes associated with cardiovascular disease. For clinical research of a large number of patients, encoded information is thus far preferable to textual information.

7.7.9 Supporting Patient Safety

As many as 98,000 patients die a year, and 10 times as many are injured each year, due to medical mistakes [34].

Many of these errors are medication errors, with 2 out of 3 of these errors due to misinterpretation of handwriting on prescriptions or medication orders. The automated patient medical record, with on-line ordering, would eliminate these handwriting errors.

Research on what causes medical errors could be supported by an automated system by allowing caregivers to record these errors and the reasons they occurred, anonymously sending this information to state or federal government organizations and to other healthcare organizations, with the automated system protecting the confidentiality of caregivers, patients and the healthcare organization by removing their identities.

7.7.10 Contextual Framework

This paper views an automated patient medical record system as separate from other clinical systems such as the hospital admission, discharge and transfer (ADT) system; the appointment and scheduling system; and the clinical laboratory system; and separate from non-clinical business systems such as billing and inventory. In reality these systems are quite dependent upon each other. Section 10.5 discusses needed interfaces between the automated patient medical record system and other systems.

Automation of the patient medical record could support electronic commerce with regard to on-line ordering of durable medical equipment, such as wheelchairs and crutches for patients, automated ordering of other supplies when needed, collection of medical payments from the government and outside insurance companies, and payments for member medical services outside the HMO. Automatic ordering and billing is possible because automation of the patient medical record would result in collection of detailed information on all orders, medical supplies, and medical services. As medical supplies are used, requests for new supplies could be periodically sent to suppliers over computer networks. When a patient encounter ends, billing of medical services could automatically occur, sending the bills to insurance companies or government agencies for payment, such as to HCFA for Medicare payments. Notification of a member encounter outside the health care organization together with a recording of medical services provided could trigger automated calculation of reasonable charges for this services; when the HMO is billed, these estimated charges can be compared against billed charges with automatic payment of reasonable charges and review of other changes .

A current standard for electronic commerce is Electronic Data Interchange (EDI), a standard for structured data, using agreed upon message standards by the sender and recipient, from the sending computer to the receiving computer [35]. Electronic commerce could occur over any computer network, such as the Internet (RPC 832) or outside the Internet via X.400 messaging networks. A company may provide a commercial network for EDI communication referred to as a VAN (Value Added Network) to subscribing companies. The United Nations is developing standards for EDI message formats referred to as UN/EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) used in Europe for exchange of healthcare data between organizations [36]; trials of UN/EDIFACT over the Internet using XML are currently in progress, with the potential of significantly reduced costs over a VAN.

Another possibility, instead of EDI, is for the government agencies and insurance companies to be subscribers to the CPR repository for patients of interest so they can pick up all medical service and order information from the CPR repository for such patients as encounters for these patients are completed. In such a case, agreements between the healthcare organization and insurer must be made to account for cases where the patient is multiply insured. The ASTM 1384 standard for the CPR also includes financial information besides clinical information.

7.7.11 Financial Aspects

HMO often do not pay for treatments they consider to be “experimental”. Further, they often restrict drugs to those in the HMO’s formulary, requiring the patient to pay more or the whole amount for other drugs; this is often part of a three tier system where “tier one” drugs (in the formulary) are entirely paid for by the HMO, “tier two” drugs are partially paid for by the patient, and “tier three” drugs are entirely paid for by the patient. Additionally, HMOs are restricting the number of visits of particular types (e.g., psychiatry visits) and requiring co-pays for some types of treatments, diagnostic tests, or medications.

As a result, caregivers devising treatment plans, making orders for diagnostic tests or prescribing medications, now have to consider the financial impact of their decisions on the patient. Thus, information on the patient’s benefits should be available to physicians, appointment clerks and advice nurses, among others.

Within the next section, it is proposed that each HMO member be assigned a Healthcare Services Representative who would serve as an ombudsman for the patient, but also be the person in the HMO who could thoroughly discuss patient benefits with the patient, in particular on what services the HMO covers and does not cover for the patient.

7.8 Actionable Information

In this chapter various information was identified as being so important that it should be immediately sent to a caregiver for action. This is referred to as actionable information.

Actionable information should be sent by the automated patient medical record system to a caregiver or care team associated with the patient, either for display, or to be printed. Actionable information could include the following:

· when a trend document (e.g., tracking blood pressures, blood glucose level, etc.) is determined to be out of range (see section 7.4)

· clinical checking of a medication with other prescribed medications determines that there is a drug/drug interaction (see section 7.7.2)

· the ordering caregiver is given an alarm that clinical laboratory results are out of range or when clinical laboratory results are returned for a STAT order (see section 7.7.2)

· a message is sent to a caregiver that the caregiver or care team must respond to (see section 7.7.3)

· clinical decision support, telling a caregiver when there is a choice of a less expensive medication than the one order, where there are duplicate orders, or when practice guidelines are not being followed (see section 17.4.9).

7.9 Another Conceptual View

The automated patient medical record system should be patient-oriented like the current paper chart. The automated patient medical record system should also be able to display the set of patients that are of interest to a caregiver.

The basic elements of a proposed automated patient medical record system are presented in figure 7.16. These elements are as follows:

· methods to identify patients of interest to a caregiver: a method tailored to the specific caregiver to select a patient and verify that the correct selection has been made

· a quick overview of clinical information for a patient: a summary of patient clinical information tailored to the caregiver (e.g., current medications, past encounters, immunizations, etc.)

· defined outcome cases, chronic care management cases, and patient cases for a patient: a list of cases tracking treatments for a patient (identifying treatment plans and related information) and patient cases (identifying case notes for a case manager)

· synopses of past encounters for a patient: a list of caregiver or automated system generated summaries of each encounter; synopses could also exist for a case and a clinical pathway

· documents making up a patient medical record: the set of documents making up the patient medical record, with documents organized by encounter, defined outcome case, chronic care management case, patient case, or clinical pathway.

· the ability to perform and record actions dealing with the patient’s care: this covers all activities to schedule or perform services and record care, including the following: (1) ordering clinical lab test, medications, diagnostic images, etc., and receiving back results, including alarms of abnormal results; (2) documenting patient care, producing documents in the patient medical record; (3) messaging between caregivers; (4) making patient appointments; (5) viewing medical and HMO reference information, including HMO guidelines and drug formulary.

The proposed automated patient medical record system would be tailorable, such as by job category or individual caregiver via agents. Tailoring could identify the scope of information available to a caregiver (i.e., the total of the information a caregiver has available to bring up for display) and how the information is connected (e.g., how selection of an item, such as an encounter, drills down to other information, such as a document list).

7.10 Tracing Current Essential Business Practices and Tracing Project Objectives to Business Requirements in This Chapter

Figure 7.17 identifies current essential business practices to preserve (see figure 4.9) and chapter business requirements, if any, that support these practices. Figure 7.18 identifies project objectives identified from chapter 5 and chapter business requirements that are derived from these project objectives.

Figure 7.17—Chapter Business Requirements and Their Relationship
to Essential Business Practices to be Preserved

Number	Essential Business Practice	Addressed in this Chapter?	Business Requirements
1	Support all caregivers listed in section 4.2	Partially	The automated patient medical record system provides capabilities for multiple types of caregivers (see all sections in this chapter) and can be tailored by type of caregiver via agents (see section 7.6).
2	Support caregiver workflow as identified in section 4.3, including providing lists of patients being seen by a caregiver or a group of caregivers	Yes	See section 7.7.5 for various types of lists identifying patients of interest to various caregivers, supporting caregiver workflow.
3	Support recording and retrieval of care documenation in the patient medical record, including retrieval of source documents that currently exist, as listed in section 4.4	Yes	Proposed care documentation is described in sections 7.2, 7.3, 7.5 and 7.7.1.
4	Generate the documents listed in section 4.4 which are derived from, but are not included in the patient medical record.	Yes	See section 7.7.4 for the inpatient clinical summary (similar to the “Kardex”) and section 7.7.2 for the medication administration record (MAR) for inpatients.
5	Support ordering of diagnostic tests and of procedures, and support return and recording of results of orders. Part of section 4.4.	Yes	See section 7.7.2 for ordering and return of results.
6	Support the principal purposes for the patient medical record listed in section 4.5	Partially	See sections 7.4 and 7.7.
7	Support demand management. See section 4.6.	Yes	See sections 7.4 and 7.7.
8	Support the HMO cost-saving methods listed in figure 4.6 where appropriate.	Partially	See sections 7.4 and 7.7.
9	Resolve problems with the current paper patient medical record listed in section 4.7.	Yes	See section 7.5.
10	Support existing clinical systems, as listed in section 4.8.	Yes	See sections 7.3.1 and 7.7.2.

Figure 7.18—Chapter Business Requirements and Their Relationship
to Project Objectives

Organiza- tional Objective	Number	Project Objective	Project Objective Addressed in this Chapter?	Business Requirement
Quality Medical Care (section 5.4.1)	1	Re-evaluate the entire clinical workflow of the HMO to completely eliminate unnecessary steps and restructure non-productive steps while incorporating the automated patient medical record system.	No
	2	Create a complete and always available patient medical record.	Yes	Store the patient medical record electronically, making it available to caregivers both inside the HMO and within other healthcare organizations. See section 7.5.
	3	Allow simultaneous viewing and update to a patient medical record.	No	A research area.
	4	Enable a caregiver to quickly find relevant information in the patient medical record by methods such as providing summarization information, organization, information retrieval and tailoring of information related to the type of caregiver.	Yes	Electronically organize the patient medical record for various types of caregivers, provide a summary of the patient's health history, enable searching for relevant information, and enable tailoring of the presentation of information based upon user characteristics. See sections 7.3,7.4,7.5,7.7.3,7.7.4 and 7.7.6.
	5	Provide methods to track a treatment for a particular condition across multiple encounters, possibly with multiple different caregivers, potentially in different departments and in different geographic locations.	Yes	Provide case management techniques to track treatments across multiple encounters. See 7.4.
	6	Automate and integrate caregiver ordering and results reporting to make it easier, quicker and more accurate.	Yes	Enable ordering and results reporting through integration of the automated patient medical record system with other HMO clinical systems. See section 7.7.2.
	7	Where possible, validate as correct all information input by the caregiver.	Yes	Validate orders and clinical information entered into documents. See section 7.7.
	8	Automate the process of identifying situations where patients are not complying with orders that seriously affect the patient's health.	No	A research area.
	9	Do automated clinical checking of medications, such as drug/drug interactions and patient allergy checking.	Yes	In the process of entrance of medication and other orders, do clinical checking of medications, such as drug/drug interactions and patient allergy checking. See section 7.7.2.
	10	Where possible, automate the identification of trends in the patient's health, especially in cases where there is an emerging health problem (e.g., an increase in the patient's blood pressure).	Yes	Provide "trend documents" which, once set up, automatically record specified values entered in documents (e.g., blood pressure) and report on situations of concern. See section 7.4.
	11	Provide information to caregivers on best practice guidelines and medical reference information.	Yes	Provide medical references, including AHCPR clinical practice guidelines. See section 7.7.7.
	12	Collect clinical information to further evidence-based medicine (identifying best treatments and practices for diseases which produce the best outcomes as determined by the best scientific evidence).	Yes	Provide case management techniques to track treatments across multiple encounters to make it easier to evaluate treatments, procedures, medications, etc. Provide research data base (data warehouse) to support evaluation of medical care. See section 7.4.
	13	Eliminate redundant entrance of information in clinical systems, eliminating possible contradictory information.	Partially	Interface the automated patient medical record system with other clinical systems to gather information on demographics, encounters and orders and results. Other information may be redundant. See sections 7.3.1 and 7.7.2.
	14	Generate letters to patients to come in for preventative health exams (e.g., colonoscopies) based upon age, sex, family history and other factors.	No
	15	Provide the ability to record a detailed social, family, environmental and genetic history of HMO members who agree to provide this information. Identify family members of these HMO members and their relationships to the HMO member, especially family members who are themselves HMO members.	No	Develop database (data warehouse) for research and for an individual HMO member use the database to predict potential future diseases. This is a research area.
	16	Explore predicting diseases from information in the automated patient medical record, including from risk factors.	Partially	Record risk factors for disease for each patient. This is a research area.
	17	For medical research purposes, enable useful access to clinical information without providing the identities of patients.	No	Develop database (data warehouse) for research and reporting.
	18	For medical research purposes, enable controlled access to clinical information to identify patients who are appropriate for specific clinical trials.	No	Develop database (data warehouse) for research and reporting.
	19	Automate quality control checks which insure that clinical information complies with accreditation agency (e.g., JCAHO) and government standards.	Yes	Develop agent code to recognize where JCAHO rules are not being followed. See section 7.6.
	20	Provide automated recognition of infection outbreaks.	Yes	Develop agent code to recognize documentation of infection outbreaks. See section 7.6.
	21	Automatically collect registry information based upon patient diagnoses and alert a caregiver when registry information should be collected.	Yes	Develop agent code to recognize and record Registry items. Develop for each kind of registry. See section 7.6.
	22	Evaluate the feasibility of digitized diagnostic images to enable quick transmission of images to medical professionals who can interpret them, display them on monitors and interpret and return the results.	No	A research area.
Reasonable cost (section 5.4.2)	23	Re-evaluate the entire clinical workflow of the HMO to eliminate or revise costly processes while incorporating the automated patient medical record system.	No
	24	Support demand management in all its forms.	No
	25	Standardize clinical system interfaces using industry standards (such as HL7).	Yes	Interface the automated patient medical record system with other clinical systems to gather information on encounters and enable ordering and results reporting using HL7. See section 7.3.1, 7.5.2 and 7.7.2.
	26	Have real-time interfaces between clinical systems to insure immediate accuracy and non-redundancy of information.	Partially	Encounters, orders, results and patient demographics would be immediately consistent. Other information might not be. See section 7.3.1 and 7.7.2.
	27	Provide automated advice on least cost best practices, including lower cost medications which provide equal or better benefits, including advice to use generic medications rather than brand name ones.	Yes	Develop agent code to recognize that best practices are not being followed and make recommendations on low cost treatments, medications and procedures. See section 7.6.
	28	Automate currently manual processes such as ordering, the MAR (the inpatient medication administration record), etc.	Yes	Automate the capabilities in section 7.7.2, including ordering and automatic creation of the MAR from inpatient medication orders.
	29	Reduce errors, including reordered tests, adverse drug reactions, etc.	Yes	Do error checking during ordering. See section 7.7.2.
	30	Support automated care documentation, including computerized generation of nursing plans. Provide this information for other clinical systems where applicable.	Yes	Record documents in source document repositories and summarize in the computer-based patient record (CPR) repositories. Provide various techniques for input of document information. See section 7.4 and 7.7.
	31	Decrease personnel requirements by electronic storage of the patient medical record and automated ordering with automatic inclusion in the medical record.	Yes	Interface the automated patient medical record system with other clinical systems to gather information on encounters and enable ordering and results reporting. Output chart documentation to CPRs and source document repositories. See section 7.5.1.
	32	Evaluate the possibility, feasibility and cost-effectiveness of off-site storage of automated patient medical record information.	No	An analysis area.
	33	For reporting based upon medical related information (e.g., HEDIS), set up automatic generation of these resports and transmission to outside agencies (e.g., the NCQA).	Yes	Develop database (data warehouse) for research and reporting from which reports can be generated and transmitted to outside agencies, e.g., via agents. See section 7.6.
	34	Identify and report on potential patient abuse such as "drug jumping", going from facility to facility for narcotics orders.	No	Requires analysis of cost-effectiveness of doing so
	35	Identify suspicious charges for medications and services when payments are to be made to outside healthcare organizations.	No	Requires further research and analysis
	36	Support automated collection of payments for medical services from the government and insurance companies via EDI. Support automated payment for medical services.	Yes	Support automated collection of payments for medical services from the government and insurance companies via EDI. Support automated payment for medical services. See section 7.7.9.
	37	Support electronic commerce, in particular DME ordering such as over the Internet.	Yes	Support electronic commerce, in particular DME ordering such as over the Internet. See section 7.7.9.
	38	Where possible, standardize hardware, system software and clinical systems within the organization.	No
	39	Design the automated patient medical record system to eliminate documentation errors identified in section 5.4.2.9 to protect against costly law suits.	Yes	Validate orders and clinical information entered into documents. See 7.7.1 and 7.7.2.
Satisfying Patient Needs (section 5.4.3)	40	After an outpatient visit, provide patients and family information on clinician orders and other information to promote compliance with physician instructions and orders and encourage greater participation of the patient in his own care.	No
	41	Get patients and their families more involved in the patient care process.	No
	42	To reengineer the care process to eliminate roadblocks to the patient and his family receiving prompt care.	Partially	Being automated, the patient chart will be immediately available to all HMO caregivers, eliminating delays in care.
	43	Personalize care for the patient.	No
	44	Evaluate the feasibility of the automated patient medical record system receiving input from monitoring systems, including "Guardian Angel" systems.	Partially	A research area.
Employee satisfaction (section 5.4.4)	45	To reengineer the care process based upon input from employees so that employees’ work activities match the most productive and least stressful methods of providing care.	No
Ability to predict (section 5.4.5)	46	Record services, tests and procedures given to patients, supplies and medications, provider time caring for patients, hospitalizations and visits, and trends in membership growth and patient utilization for prediction of HMO costs in the future.	Yes	Develop financial database (data warehouse) for research and reporting. Inform caregivers of patient's costs for medication and procedures as determined by patient's benefits. See section 7.7.2 and 7.7.9.

References

[1] Alissa R. Spielberg, JD, MPH, “On Call and Online: Sociohistorical, Legal, and Ethical Implications of E-mail for the Patient-Physician Relationship”, The Journal of the American Medical Association, October 21, 1998, Vol. 280, No. 15.

[2] ASTM, E 1384 - 99 Standard Guide for Content and Structure of the Computer-Based Patient Record, ASTM, 1999.

[3] Edward P. Richards III,JD,MPH, Katherine C. Rathburn,MD, MPH, Medical Care Law, An Aspen Publication, 1999, pp. 198-198.

[4] Stanley Loeb, Mastering Documentation, Springhouse Corporation, 1995, pp. 6, 72-76.

[5] Edward H. Shortlife and G. Octo Barnett, “Medical Data: Their Acquisition, Storage, and Use”, Medical Informatics: Computer Applications in Health Care, Addison-Wesley Publishing, 1990, pp. 61-64.

[6] Agency for Health Care Policy and Research (AHCPR) Clinical Practice Guidelines, found in Internet under http://text.nlm.nih.gov/ngc.html, with guidelines for acute pain management, urinary incontinence, pressure ulcers, etc., AHCR.

[7] David L Sackett, William MC Rosenberg, JA Muir Gray, R Brian Haynes, W Scott Richardson, “Evidence-Based Medicine: What it is and what it isn’t”, British Medical Journal, 1996; 312: 71-2.

[8] Centers for Disease Control and Prevention, “About Chronic Diseases” on the Internet at http://www.cdc.gov/nccdphp/about.htm.

[9] National Digestive Diseases Clearinghouse, Chronic Hepatitis C: Current Disease Management, http://www.niddk.nih.gov/health/digest/pubs/chrnhepc/chrnhepc.htm.

[10] Cardiac Solutions, Providing quality outpatient and disease management, on the Internet at http://www.ralinmed.com/2a.html.

[11] National Jewish Medical and Research Center, Disease Management Services, http://www.njc.org/dm1.html, Disease management for asthma, COPD, bronchitis, emphysema.

[12] George E. P. Box, William G. Hunter, J. Stuart Hunter, Statistics for Experimenters: An Introduction to Design, Data Analysis, and Model Building, John Wiley & Sons, Inc., 1978, pp. 556-562.

[13] Donna W. Markey, R.N., M.S.N, A.C.N.P.-C.S., Jim McGowan, M.B.A., John B. Hanks, M.D, “The Effect of Clinical Pathway Implementation on Total Hospital Costs for Thyroidectomy and Parathyroidectomy Patients”, The American Surgeon, Presented at the 68th Annual Meeting, Southeastern Surgical Congress, Orlando, Florida, February 5--8, 2000, found on the Internet at http://www.onlinejournal.net/sesc-TAS/2000/66/6/html/66_6_533.html.

[14] Alex Macario, M.D., David A. Lubarsky, M.D., “Why are Hospitals Enamored with Clinical Pathways?”, October 1998, http://www.asahq.org/NEWSLETTERS/1998/10_98/Why_1098.html.

[15] Jagdish C. Kohli, Pacific Bell, Unpublished Talk on “Emerging Medical Technologies—in the 1990s and beyond”, for IEEE Oakland East Bay Communications Society, at Pacific Bell, San Ramon, CA, February 29, 1996.

[16] Peter Szolovits, PhD, William Long, PhD, Christopher Cimino, MD, James Fackler, MD, Yao Sun, MD, Charles Huskins, Cedric Priebe, MD, Alton Liu, MA, “Excerpts

from NIH (National Institute of Health) Form for LM-94-002”,

http://medixb.webnet.net/CARE/CPR/emrs.html.

[17] ASTM, E 1869 - 97 Standard Guide for Confidentiality, Privacy, Access, and Data Security Principles for Health Information Including Computer-Based Patient Records, ASTM, 1997.

[18] Marilynn E. Doenges, Mary Frances Moorhouse, Alice C. Geissler, Nursing Care Plans: Guidelines for Individualizing Patient Care, Edition 4, F. A. Davis Company, Philadelphia, 1997.

[19] Ronald Arky, MD, editor, Physician’s Desk Reference, 53rd Edition, Medical Economics Company, 1999.

[20] DEA web site for DEA drug schedule.

[21] Ravi Kalakota, Andrew B. Whinston, Frontiers of Electronic Commerce, Addison-Wesley Publishing Company, Inc., 1996.

[22] Editors, William B. Frakes, Ricardo Baeza-Yates, Information Retrieval: Data Structures & Algorithms, Prentice Hall PTR, 1992.

[23] William Hersh, Information Retrieval: A Health Care Perspective, Springer-Verlag, 1996.

[24] Jacqueline W. T. Wong, W. K. Kan, Gilbert Young, “ACTION: Automatic Classification for Full-Text Documents”, SIGIR Forum: The Special Interest Group on Information Retrieval, ACM Press, Spring 1996, pp. 26-41.

[25] http://www.yahoo.com on the Internet.

[26] http://www.google.com on the Internet.

[27] Linda Barlow, “A Helpful Guide to Web Search Engines – How Search Engines Work”, The Spider’s Apprentice, http://www.monash.com/spidap4.html.

[28] Lotus Development Corporation, “Lotus Whitepaper: Domino Document Manager”, February 1997.

[29] Russ Eldelman, “Enterprise Document Management: Myth or Reality?, Today true EDMS is still more fluff than substance”, IW, May 5, 1997, Vol. 6, Issue 7, pp. 30-33 (an article critical of enterprise wide documentation management systems noting that no EDMS vendor can reference an account that fully deploys EDMS throughout the enterprise).

[30] Yuri Rubinsky, Murray Maloney, SGML on the Web: Small Steps Beyond HTML, Prentice Hall PTR, 1997.

[31] Davis Community Network, http://www.dcn.davis.ca.us/~csandvig/ip/example.html, which shows an example of HTML and a resulting screen.

[32] Lisa Rein, “Developing with XML: Gearing Up for Web-Native Applications”, Software Development, April 1998, Vol. 6, No. 4.

[33] W3C, Extensible Markup Language (XML) 1.0, W3C Recommendation 10-February-1998, http://www.w3.org/TR/REC-xml.

[34] Linda Kohn, Janet Corrigan, Molla Donaldson, Editors, To Err Is Human: Building a Safer Health System, Committee on Quality of Health Care in America, Institute of Medicine, November 29, 1999.

[35] Valerie Leyland, ELECTRONIC DATA INTERCHANGE, A Management View, Prentice Hall, Hertfordshire, UK, 1993.

[36] See the Hewlett Packard Internet site http://www.hp.com to get more information on the HP Andover Working Group.

NEXT

TABLE OF CONTENTS

Copyright © 2000-2001 Michael R. McGuire

Duplication not permitted without express written permission

Comments? mailto:Michael.McGuire@abac.com