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
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).