13. System Analysis: Software and Hardware Design of the
Automated Patient Medical Record System

13.1 Project Context: System Analysis and Design

The internal design of an automated system must support its external design including its user interface and employee workflows when the system is used. And the collective overall design of automated systems functioning together—called the system architecture—must support the identified business requirements for which the systems were built.

This system architecture and these internal structures include the following:

· the various computer systems

· application program design

· databases

· hardware, including networks

· system software such as operating systems

· internal data

· interfaces with other systems

· implementation of business policies.

In the systems analysis step—see figure 2.6—the internal design of each automated system is planned, and how organizational automated systems will function together as a whole is planned. System requirements for each automated system are developed identifying an overall design of each system and the design of its component parts: the system's hardware, software, databases, infrastructure, and interfaces with other systems.

In the systems analysis step, integration of automated systems is planned so the systems will function together: (1) The overall system architecture of the automated systems functioning together is identified. (2) Requirements for the performance of the systems and their future growth (scalability) are incorporated into the system designs so they fulfill the requirements of the Performance and Scalability Plan developed previously by technical personnel in the Evaluation step. (3) Requirements for interfaces between systems are identified, adding to those defined during the Business Reengineering step and identified during the design of other automated systems, with the description of the newly identified interfaces added to an organizational Interface Plan so changes can also be made in systems outside the project. (4) Business policies of the organization are implemented as previously planned, which could potentially be implemented across many automated systems.

A business policy (for example, rules for the assignment of a primary care physician to an HMO member) could be implemented through a combination of employee procedures in handling the business policy, software (ideally kept distinct from other software and referred to as an "agent"), user interfaces, and information on databases. The software, user interfaces and database information could be distributed across many different automated systems. Creating a document that describes an overall business policy and its implementation enables non-computer personnel to work together with technical personnel in the implementation of, and any future change to, the business policy.

Potential system designs can be discussed and evaluated by creating models—in this book called “conceptual views”—of the system.

13.2 The Basics of Computer Software System Design (and Also of the Design of Watches)

Designing a computer software system is analogous to designing a watch. Assume that a watch company was designing a new watch as pictured in figure 13.1. There would be designers of the outside of the watch and its external functions. There would be engineers to design the internals of the watch.

The external functions of the watch might be the following:

· to tell time in terms of minutes and hours.

· to tell seconds via a second hand

· to allow winding of the watch.

The designers of the externals of the watch would have a black box view of the watch. It is not required that they look inside the watch to know how the watch functions.

The engineers of the watch would need to have a white box view of the watch: they would need to understand the watch’s external functions and also would need to be able to picture what the inside of the watch would look like. In this way, they could create the internal workings of the watch—the gear assembly, the mainspring, etc.—that would support the external functions of the watch.

Design of a computer software system is completely analogous to the design of a watch. There is an external view of the system with its various external functionality: this is the system user’s view of the system. The business group and analysts design the external system seen by the users and do not need to know how the internal system works. They would only need a black box view of the system.

The system analysts and technical group design the internal system. The internals of the system—the software, hardware, databases and interfaces—are created to support the external design of the system. The system analysts and technical group build the internal system, creating internal subsystems, so its supports the external system and its functions. Thus the system analysts and technical group need to both understand how the system functions externally and how it would work internally. They would need to have a white box view of the system.

This chapter identifies the basic tools—the system software, hardware, databases and network interfaces—needed to implement the internals of the automated patient medical record system. And this chapter delves into the implementation of the system using these tools. The application software implementing the automated system—the internal workings—would be broken up into subsystems (e.g., alert system, display subsystem), portions of code that together implement the external functions of the system.

13.3 A System Architectural Conceptual View

We start with another conceptual view of the system, a conceptual view looking at the automated patient medical record system from a system architectural point of view. See figure 13.2.

The automated patient medical record system uses information from many other clinical systems in the HMO. The automated patient medical record system receives encounters from encounter systems enabling the patient medical record to be organized by encounter. The automated patient medical record system sends orders to other clinical systems and receives results back.

The automated patient medical record system stores information in the distributed universal patient record, consisting of CPR repositories storing summaries of chart information and source document repositories or in chart rooms storing source documents.

The HMO automated patient medical record system will be assumed to be composed of a central HMO system, and local HMO systems, each handling a set of facilities. This proposed break up of the automated patient medical record system is explained in the next section.

Through the HMO automated patient medical record systems,

· a caregiver can do documentation on the patient, which stores patient clinical information within the local HMO database,

· the caregiver can do ordering, sending the order to another clinical system (e.g., the Clinical Laboratory System for a lab order, the Pharmacy System for a medication order, the Radiology System for a diagnostic imaging order, the Appointment System for an appointment or wait list request, the Medical Records System for ordering the paper chart),

· the caregiver can view results and order statuses received back from a clinical system (e.g., the Clinical Laboratory System for lab results, the Pharmacy System for administration of medication, especially within a hospital, say from an automated MAR, the Radiology System for diagnostic images and transcribed interpretations, the Medical Records System for the status of the ordered paper chart).

· the system can receive remotely located patient clinical documentation from other local HMO systems, other HMOs, CPR repositories and source document repositories.

· the system can receive and filter information from systems monitoring the patient, such as patients in the cardiac or respiratory ICU and from at home Guardian Angel systems (see section 5.4.3.6).

Both the automated patient medical record system and the universal patient record (i.e., the CPR repositories and the source document repositories) require that patient clinical documents be tied to encounters. Clinical systems would inform the automated patient medical record system of new encounters and changes in encounter status (e.g., the ADT System would inform the automated patient medical record system of admissions, discharges and transfers; the Appointment/Registration System would inform the automated patient medical record system of new appointments, canceled appointments, the patient showing up, the patient not showing up; the Membership System would inform the automated patient medical record system of new patients to the HMO).

Periodically, the automated patient medical record system would send source document information to a Source Document Repository and summarized patient clinical information to the CPR Repository, two parts of the universal patient record. Upon sending clinical information to the universal patient record, the automated patient medical record system would also send the associated encounter.

13.4 The Automated Patient Medical Record System

There are many possible hardware/software designs for the automated patient medical record system for a large healthcare organization such as our large HMO. This section chooses one possible design and proposes details of the design, justifying choices made. Many other logical choices could have been made for the hardware and software design for our automated patient medical record system.

The following are some possibilities: (1) one central automated patient medical record system, e.g., a mainframe computer, (2) multiple local, facility-based, systems (and no central system) and (3) a central system and one or more local, facility-based, systems. (A small healthcare organization might suffice with a single facility-based system.)

Choice 1 simplifies databases by centralizing them and is the least risky because it uses technology that has been around many years (e.g., CICS—see section 16.3.1). Its disadvantages are that it is difficult to make full use of GUI interfaces, its requires a very expensive computer and networks, and a very expensive support staff, and it has potential to have bad user response time due to the processing power being concentrated to one, or a few, computers.

Choice 2 makes it difficult to have any sort of centralized control, which I view as necessary in certain circumstances.

Choice 3 is proposed here. See figure 13.3. The automated patient medical record system would be a distributed one, with a central HMO system and local HMO systems, with each local system handling caregivers within a set of facilities within the HMO. A local system would perhaps be composed of a server, a local database and workstations. Each local system is responsible for storing the source documents created in the facilities it supports. Such a set of facilities supported by a particular local system will be referred to here as a “distributed facility group”. All the source documents generated at the set of facilities (the distributed facility group) that have not yet been downloaded to a source document repository would be stored in a local HMO system database. In the local system there would be complete summaries of patient clinical information for all patients currently being seen within the distributed facility group, together with a list and locations of all other source documents for these patients.

The central system would also keep summaries of patient clinical information, such as in the CPR repository, and a list and location of all source documents for all HMO members. It would not store the source documents.

The reasons for the above automated patient medical record system architecture are the following:

· Each local system for a distributed facility group would be responsible for the chart (source document) information it created and not responsible for chart information created by other facilities; this would make the system scaleable if systems in outside healthcare facilities or other regions of the HMO were added.

· The central system could serve as a controller to insure that the local system for a facility where an encounter was to occur had an up-to-date copy of a patient clinical summary and a list and location of source documents at the time of a patient admission or outpatient visit; this would allow a complete set of this information to be stored centrally when no encounter was occurring and not require complex communication between distributed systems.

· The central system could serve as a focal point to record a patient’s clinical activity outside the HMO in the CPR repository and to send out source documents to the source document repository and the location of these source documents to the CPR repository; this would simplify communication between the healthcare organization and the outside world.

· The central system could serve as a focal point to pick up clinical information from outside the HMO for patients not previously seen by the HMO, such as new HMO members; since this process may not be related to encounters, it is appropriately done by the central system, rather than the distributed systems.

In the System Analysis step, the actual hardware, operating system(s) and database management systems making up the automated patient medical record system are also be identified.

13.4.1 Central System

The central system as envisioned here would be a computer system that is a portion of the distributed automated patient medical record system for the HMO. The central system would be responsible for storing patient clinical summary information for all patients in the HMO, responsible for handling communication with the outside world, such as with the CPR and source document repositories, and responsible for processing orders and encounters received through interfaces with other HMO clinical systems.

The central System would store patient clinical summary information such as might appear in an overall patient clinical summary, preferably in the same format as the CPR repository, perhaps in ASTM E1384 format. This would include patient demographics information, encounters, medications, health problems, etc.

When a patient was identified as scheduled to be admitted, scheduled to come in for an outpatient visit (by the appointment system), or when an admission, outpatient visit or ED visit actually occurred as identified by the ADT or registration system, the central system would inform the appropriate local system of the admission, visit or pending admission or visit. Clinical summary information would be sent down to the local system for the facility of the admission or visit. The local system might already have much of this information and thus transfer of the total information may not be necessary.

When the membership system identified a new patient to the HMO, the central system would go to the CPR repository to try to pick up clinical summary information for the patient, identifying encounters and clinical summary information from other medical institutions. The HMO could also signal the CPR repository that future outside HMO patient clinical summary information is to be passed down to the HMO.

A local system where the patient was just seen would pass patient clinical summary information for the encounter to the central system so it could be included in the overall clinical summary for the patient. When the location of source documents changed, say from a local system to a source document repository, the central system would be informed so locations of source documents kept in the central system and the CPR repository could be updated.

13.4.2 Local Systems

A local system is a computer system that is a portion of a distributed automated patient medical record system for the HMO. A local system records patient clinical information for a set of HMO facilities and performs all the functions of the automated patient medical record system for caregivers at these facilities.

A local system would control the user interface and associated functions described in Chapter 12 for caregivers working with a set of HMO facilities, with this set of facilities referred to as a distributed facility group. In particular, the local system would be responsible for recording caregiver activities within these facilities. These activities would be recorded on documents, such a H&P’s and Progress Notes. Orders sent to other clinical systems through the central system would be recorded. Results coming back from other clinical systems through the central system would be recorded. Alarms of abnormal or panic results would be immediately sent to the ordering caregiver. E-mail/messages sent by caregivers within the distributed facility group would be recorded; e-mail/messages coming in to caregivers in the distributed facility group would be recorded; the e-mail/messages may be included in the patient’s chart.

When the central system informs the local system of an admission or visit or pending admission or visit, the local system would record this on its databases so that future documentation and orders for the encounter could be categorized under this encounter. The central system would insure that the local system would have a complete overall clinical summary for the patient. The local system could have agents related to admissions, outpatient visits, or ER visits, which might pick up source documents for previous encounters from other local systems or from outside the HMO; alternatively, these source documents would only be ordered upon caregiver request.

During or at the end of an admission or visit, the local system would send information summarizing the encounter and information on the existence and location of associated source documents to the central system, which would in turn send the changed locations to the CPR repository.

Periodically, the local system could off-load source documents to a source document repository, informing the central system and CPR repository of the new locations of these source documents. Space for the source documents on the local system could then be reused.

Also, determined by agents, space for patient clinical summaries in the local system could be reused, perhaps on a least-recently-used basis, when an encounter had not occurred for a long time. In such a case, the next time an encounter occurred for the patient would result in significant clinical summary information be transferred down to the local system from the central system.

13.4.3 Remote (Outside HMO) and Virtual Systems

A remote system is any part of the automated patient medical record system outside the HMO. In order to minimize network traffic with remote systems for patients being seen or HMO patients seen outside the HMO, CPR repository and source document repository information could be retrieved from remote systems, perhaps at off-hours, and stored on a computer system referred to as a virtual system. Thereafter, the virtual system would function like another local system except that it would handle remote, rather than local information

A virtual system could also potentially be used as a back up system when another local system is down.

13.4.4 Other Clinical Systems

The automated patient medical record system would use data from other clinical systems and would send data to other clinical systems for encounters and ordering. These clinical systems could include encounter and ordering systems as described in the next section.

For generality, our design would be able to handle both clinical systems for the entire HMO (connected to the central system) and clinical systems for particular facilities of the HMO (connected to the associated local systems). For example, there might be an ADT hospital system for the entire HMO and various clinical laboratory systems throughout the facilities.

Clinical systems could be connected to the automated patient medical record system via an interface engine, which for example might accept HL7 inputs and convert them to a form where the central or a local database can be updated. See section 13.11.5 for a discussion of interface engines.

13.5 System Communication with Other Clinical Systems

As mentioned in section 13.4, the automated patient medical record system needs to receive information from various other HMO clinical systems. The systems fall into the following two categories:

· encounter systems

· ancillary, or ordering, systems.

An encounter system identifies encounters, which would be used by the automated patient medical record system to order patient medical information by encounter. The encounter system would identify an appointment, outpatient visit, admission, discharge, transfer, or other event that starts or changes an encounter for a patient.

An ordering system would receive orders from caregivers through the automated patient medical record system. The automated patient medical record system would send an order to the ordering system for execution. In turn, the ordering system would return changed statuses for the order and eventually any results of the order (e.g., clinical lab order test results).

The following encounter systems are assumed:

· A hospital system (identified as an ADT system for admission, discharge and transfer)

· Outpatient systems, including an appointment system and a registration system

· Surgery scheduling system.

(When a patient comes in for outpatient care in either an outpatient clinic or the Emergency Department, then the visit is recorded by the registration system, with any fees being paid through this system.)

The following ancillary systems to which orders can be sent which would pass them to a performing area are assumed:

· Clinical Laboratory System

· Anatomic Pathology System (examination of body tissue or other items removed from the body)

· Pharmacy System

· Radiology System (handling x-rays, MRIs, etc.)

· Durable Medical Equipment (DME) System. (ordering wheelchairs, walkers, etc. for the patient)

Also, consultation requests can be sent to individual physicians and to performing areas, which also function similar to orders.

Encounter systems must send encounter events (in the form of admissions, pre-admits, registrations, appointments, surgeries, etc.) to the automated patient medical record system, as all patient clinical activities and associated documents are grouped by encounter.

Ordering systems must accept orders from the automated patient medical record system, send back order statuses and/or return results and inform the ordering caregiver of alarm conditions (e.g., abnormal or panic results). Orders can most often also be grouped by encounter.

In addition, there are databases available to these other clinical systems which contain the translation information necessary to interpret encounters, orders and results, and other documents created within their systems; these are sometimes referred to as “master files”. This master file information must be transferred down from these other clinical systems to the automated patient medical record system, either upon initial system load of the automated patient medical record system or whenever the information changes within these other clinical systems; or alternatively, this information could be passed down only when needed by the automated patient medical record system or reside on shared databases. This master file information allows the automated patient medical record system to validate caregiver entered orders, interpret results, organize encounter information and interpret document information.

Included in the master file information passed down to the automated patient medical record system might be the following:

· a drug compendium which validates drug orders, includes both HMO formulary and non-formulary drugs, enables clinical checking (drug interaction checking) and enables drug costing

· a clinical laboratory test directory to validate clinical laboratory orders, which includes test names, test measurement units and reference ranges

· a DME formulary, which lists and describes all durable medical equipment (DME) offered to patients.

Other non-order related “master files” existing in other clinical systems include the various information included in section 13.8.2: locations, resources, including caregivers, rooms and equipment, and patients.

The standard for communication between clinical systems, including master files, is HL7 [1], an applications level network communication protocol for health care systems.

Clinical information is shared between systems and is usually stored on a database called the clinical data repository (CDR). This information constitutes a large part of the information needed by the automated patient medical record.

For the proposed system design proposed here, again one of many possible solutions, interfaces with other clinical systems would be through either the central system or a local system. When it comes to orders, local systems may sometimes function like these other clinical systems: A consultation request from within the local system is also treated as an order; such an order may be sent from one local system to another via the central system. Master files might then exist on each of the local systems to speed verification of orders and other documents entered by the user.

13.6 A Universal Patient Record

The structure of a universal Patient Health Record must be agreed upon by a lot of people and healthcare organizations, insurance companies and government organizations. My conceptions of such a universal patient record have been presented previously in Chapter 6 and section 7.5.1 and are described further in this section.

The universal patient record consists of patient-centered clinical information that may be distributed throughout multiple databases and multiple healthcare or commercial organizations:

· Computer-Based Patient Record (CPR) Repository: Summarization of clinical information for each patient encounter, together with documents that may cross encounters, including defined outcome cases, chronic condition management cases, clinical pathway documents and trend documents. The locations of source documents for each encounter will also be stored. A nationally, or internationally, agreed upon standard format for information in this repository must be developed; an example is the ASTM E1384 standard for patient health records.

· Source Document Repository: A place for electronic storage of documents, including orders and results, created during the care of the patient. These documents are ordered by encounter. The format of source documents stored would be that of the healthcare organization where the document was created, in order to preserve the appearance of the document when it was created. The CPR repository could identify where the source documents are located, whether in a chart room on paper, or in a source document repository in automated form

· Patient Registry: A mechanism to record the patients that are of interest to each healthcare organization, insurance company or other organization. Whenever a CPR repository detects an addition to the CPR for a patient or a new source document being created, the CPR repository would inform the patient repository and the appropriate healthcare organization, insurance company or other organization would be informed about it, so the new information can then optionally be picked up by that organization.

· Source Document Chart Room: A location for storage of paper charts. The CPR repository could identify that source documents for an encounter are located in such a chart room.

· Clinical Practice Guideline Repository: A place for electronic storage of clinical practice guidelines which may be referenced by source documents or the CPR.

· National Patient Identifier Assigning Authority: A national organization to generate patient identification information used to uniquely identify a patient. The location will return either an existing national patient identifier for the patient or a new national patient identifier. This can be used to create CPR information.

13.6.1 A Universal Patient Record Network and Patient Registry

All the elements making up the proposed universal patient record are connected via a network (see figure 13.4). The purposes of the universal patient record are

1. to inform a healthcare or other organization of a patient encounter occurring outside the organization for a patient of interest so the organization can pick up the patient encounter information from the CPR repository and from source document locations

2. to enable a healthcare organization to determine the locations of all previous encounter information for a new member to the healthcare organization, or for a non-member visiting the healthcare organization, so the healthcare organization can pick patient encounter information in CPR repositories and source document locations.

Figure 13.4 shows what happens, step by step, when a patient encounter occurs for an HMO patient at a healthcare organization other than the HMO.

· Step 1: The patient is being cared for during an encounter in a healthcare organization outside the HMO where the patient is a member. Through an automated patient medical record system, documents are created and orders initiated and results received. During this process, source documents and CPR repository information are created. Because a universal patient identifier is used within the CPR repository, if none is yet assigned, an inquiry of an outside assigning authority needs to be done to get the patient identifier for the patient. Documents created could optionally reference a national clinical guideline; in such a case, a clinical guideline repository could be assessed to bring up the latest clinical guideline for a disease or condition for the caregiver.

· Step 2: Once the encounter is complete, patient medical record summary information is sent to the CPR repository and source documents are either saved in paper form in the chart room or sent electronically to a source document repository. Also sent to the CPR repository are the locations of source documents, whether in a chart room or in a source document repository.

· Step 3: The CPR repository then informs the patient registry of the new CPR repository information, and the patient registry informs all healthcare organizations or insurance companies who have an interest in the patient’s encounters. One of these is the HMO where the patient is a member.

· Step 4: The HMO requests and receives patient encounter information from the identified CPR repository and from any source document repository. The HMO could also order paper charts from the healthcare organization of the encounter.

Figure 13.5 shows what happens, step by step, when an HMO has a new member or a non-member visit.

· Step 1: The HMO membership system informs the HMO automated patient medical record system of a new member or the appointment or registration system informs the automated patient medical record system of a non-member visit to the HMO. The automated patient medical record system makes a request of the patient registry to identify all CPR repositories where the new member has clinical information.

· Step 2: The HMO picks up patient encounter information from CPR repositories which includes source document locations.

· Step 3: The HMO may request source documents from the source document repositories or request copies of paper patient charts from chart rooms in other healthcare organizations.

13.6.2 CPR Repository

The CPR Repository contains a summary of patient medical record information. The information in the CPR repository will be stored in national (or possibly international) standard data formats. See figure 13.6.

To produce clinical information to send to a CPR repository, patient chart information input locally must first be converted from the data in local formats to data in the national (or international) formats. There must therefore be information within the healthcare organization to do this translation from the local formats to the national formats.

When CPR repository information is transferred to a healthcare organization via network transmission, it will be in the national standard formats. When it is displayed in patient clinical summaries it will more than likely also be in national formats. One possibility is that pressing a right mouse button over a displayed data element, or button of another pointer device, might show the local value for the data element (e.g., when the right mouse button is pressed when the cursor is over a national patient identifier then the local healthcare organization medical record number would be displayed). This conversion requires information within the healthcare organization to translate national data formats to local formats.

13.6.3 Source Document Repository

The Source Document Repository contains the documents created at a healthcare organization during patient encounters. See figure 13.7. In order to preserve the format of a source document as it appears within the healthcare organization where it was input, each source document will be saved electronically as a printed form in the format used by the healthcare organization using the local healthcare organization’s data formats. In order for other healthcare organizations to use the source document, saved with each source document data element will be the national format values for the data elements.

When a source document is displayed within another healthcare organization, it will be displayed in the form of the printed form at the healthcare organization that created the document. Pressing a right mouse button over a displayed data element, or button of another pointer device, might show the national value for the data element.

It is expected that HMO source documents in source document repositories will initially be stored in the local format of the HMO. Over time, HMO source documents will probably evolve to use the national data formats contained in the CPR repository.

13.6.4 Clinical Guidelines Repository

A clinical guidelines repository electronically stores clinical practice guidelines. Since a guideline could change over time, a guideline might have several different versions over time, which may all be stored in the repository. A clinical practice guideline might be referenced in a CPR repository, simply by referencing a clinical practice guideline repository location, an identifier for the guideline and a date or version number for the guideline.

13.7 Staging Information

Staging is transferring patient clinical data from a remote to a local computer before it is needed, instead of at the time needed, so it will be there when it is needed, e.g., at the time of an encounter. This would use similar technology similar to “Internet cacheing” that speeds Internet access by storing popular web pages on local computer systems, such as is employed by Akamai and Inktomi.

See figure 13.8. Transferring patient medical record information between platforms (e.g., the CPR repository or source document repository, the central computer, the local computer, another local computer and the workstation) takes significant time. It is thus beneficial to do these transfers ahead of the time that the transferred information is displayed to the caregiver. Often if a caregiver has to wait to receive patient chart information, he will just decide to do without it.

For example, the clinical summary could be staged (i.e., transferred down) from the central computer to a local computer at the time an appointment or preadmission is made. The clinical summary could be staged from the local computer to a workstation at the time of the patient appointment or registration for the outpatient visit or at the time of the inpatient admission. The clinical summary could then be immediately available on the physician’s workstation immediately before the patient is seen.

13.8 Data and Data Bases

This section describes data and data bases needed by the automated patient medical record system. It primarily uses entity-relationship (ER) diagrams to describe this data. Entities here are business objects (e.g., bed, user, member, patient, etc.), which may correspond to records on the database and object classes within programs. The relationships between these entities are shown in the ER diagram (e.g., is-a, is-part-of, works for, was seen by, etc.)

ER diagrams presented here use a notation, United Modeling Language (UML), agreed upon by three computer software professionals, Grady Booch, James Rumbaugh, Ivar Jacobseon [2], who each advocated use of object-oriented design, but who each previously had his own notation for object models. The meanings of various notational elements are presented in figure 13.9.

Basic types of relationships between entities are generalization, where one entity is a sub-type (e.g., dog) of another entity (e.g., animal)--also referred to as inheritance or an “is-a” relationship; aggregation, where one entity (engine) is “a part of” another entity (e.g., car); and association, where a relationship exists between instances of entities (e.g., a company has a number of offices, a person works for a company).

Associations may be a one to many or a many to one relationship (e.g., a company has many offices), a one to one relationship (e.g., an HMO physician has one primary work location), or a many to many relationship (a patient may be scheduled to be seen by many physicians today, and a physician may be scheduled to see many patients today) or other multiplicities. ‘*’ means many. x..y means from x to y instances (e.g., 0..1 means 0 or 1 instances).

Association classes allow you to add data to describe formal associations. For example, a person could be an employee of a company with the relationship between them described by employment information or a contract.

Database design should begin early in the Business Analysis step and continues on to the Development step. Database design consists of two parts: Logical database design and physical database design.

Logical database design consists of two parts: (1) the identification of business objects whose information is to be stored on the databases, and the identification of the relationships between these objects, and (2) the identification of sets of data (“tables”, or “records”) making up the database and the format of data elements making up each set of data.

The objects and relationships can be described by the ER diagrams. Identification of business objects begins in the Business Analysis step. The ER diagrams with objects and relationships between them occurs in the Business Analysis and the Systems Analysis steps.

The sets of data—tables for relational databases—are determined in the Systems Analysis step. See section 13.13.

Physical database design consists of defining how the databases will be stored on disks or other storage media. Physical database design is part of the Systems Analysis and Development steps. See section 13.13.

13.8.1 Operational Databases Versus Data Warehouses

It is useful to distinguish operational databases, those used on-line during day-to-day operations of the business, and analytic or research databases, those used by researchers or executives for analysis. Analytic or research databases have been termed data warehouses.

Whereas operational databases are often distributed, i.e., are fragmented, existing at many locations, data warehouses almost always exist at one location. Data warehouses are most often created by collecting information from many operational databases on a periodic basis (e.g., daily, weekly or monthly) and storing them in one location usually through off-line processing at night (i.e., during batch processing). Reference [3] presents the following definition of data warehousing: “Data warehousing is a process, not a product, for assembling and managing data from various sources for the purpose of gaining a single, detailed view of part or all of a business”.

The structure of data warehouses and operational databases are indistinguishable. They both are often relational databases consisting of tables (see section 13.13 and figure 13.52).

A significant difference between operational databases and data warehouses is that operational databases require quick access by lots of different application programs without any one program locking out the others, while quick access to data warehouses is not as important, as users doing research, analysis or discovery are few and probably are willing to wait a long time for results.

Operational databases are optimized for a specific set of relationships, those relationships that are most commonly used during operations, while data warehouses are used to discover useful (possibly previously unknown) relationships which could provide useful information for running the organization or doing medical research. Thus ER diagrams are much more applicable to operational databases.

Accessing operational databases on-line is done through system software referred to as on-line transaction processing (OLTP) systems (see section 17.3.1), while access to data warehouses is through system software referred to an on-line analytic processing (OLAP) systems. OLTP is the processing of transactions by computers in real time for day-to-day business operations, while OLAP is the processing of transactions to analyze data relationships to discover patterns, trends and exceptions. Figure 13.10 identifies the differences between OLTP and OLAP.

Figure 13.10—OLTP Versus OLAP

Criteria	OLTP	OLAP
Activities	Supports a business' day-to-day activities.	Analyzes data previously occurring day-to-day activities.
Time Scale	Current data.	Historical data for trend analysis.
Transaction Length	Short database transactions.	Long database transactions.
Type of Access	Online update/insert/delete.	Batch update/insert/delete.
Update Rate	High update rate.	Low update rate.
Normalization	Normalization is promoted.	Denormalization is promoted.
Volume	High volume transactions.	Low volume transactions.
Recovery	Transaction recovery is necessary.	Transaction recovery is not necessary.
Database Location	Possibly scattered among a variety of databases	Usually centralized in a single database.
Indexing	Update performance is maximized by limiting the number of indexes.	Optimize ad hoc query performance by including lots of indexes.

13.8.2 Operational Databases

Operational databases are those used on-line during day-to-day operations of the business.

It is useful to distinguish an operational database as a corporate database or application database. A corporate database is a database you want all automated systems in the organization to use that need a particular type of data so that that data can be shared between automated systems and has a consistent format. When data is not specific to a particular automated system or set of closely related automated systems, then it should, in general, be in a corporate database. A corporate database can be stored in one location or replicated in multiple locations with an update at one location distributed to all other locations.

An application database is any database that is not meant to be used by all automated systems in an organization. It contains data specific to a single automated system or to a set of related automated systems.

Data in healthcare databases, especially corporate databases, may potentially be shared nationally or internationally. It is thus beneficial to use national or international standards for data in databases where these standards exist. See the Appendix.

13.8.2.1 Locations

The following are applicable terms related to locations in an HMO:

· organization: the HMO

· region: an administrative region within an HMO

· facility: a medical center, or a satellite of the medical center, a Medical Office Building (MOB)

· distributed facility group: a group of facilities which use the same (local) distributed system

· administrative facility group: a medical center and its satellite facilities under the same administration

· facility department: an administrative department within a facility (e.g., Medicine, Pediatrics, Emergency Department)

· subdepartment: a breakup of a department for some purpose (e.g., appointment booking)

· performing area: a location where an order can be sent to be put on a Work List or to be transferred to another computer software system, another clinical system, for execution of the order (see work list description under Patient Lists in section 13.8.2.3)

· delivery location: a location where a paper chart or order can be sent.

· nursing unit: an area of the hospital serving a specific purpose (e.g., ICU, MED, etc.)

· nursing station: a nursing station within the unit

· room: a room handled by the nursing station

· bed: a bed within the room.

An Entity Relationship (ER) diagram of these locations is pictured in Figure 13.11. This is likely to be a corporate database.

13.8.2.2 People and Other Resources

There are various types of people and non-human resources which are represented in the system.

· caregivers: A caregiver is an individual who delivers care to patients. Examples are a physician, nurse, lab technician, unit assistant or social worker.

· users: caregivers, system maintenance personnel and other persons who are allowed to use the system

· resources: caregivers and rooms, equipment and other things that may be scheduled

For a caregiver who is allowed to do ordering, an ordering caregiver, ordering capabilities might be described by information associated with this entity and a printer location to send alarms on STAT or abnormal results might be identified.

Job categories of a user, e.g., an inpatient nurse, outpatient physician, etc., may be identified by the job category entity. This may control how agents work—see section 13.8.2.8.

See Figure 13.12 for an ER diagram. This is likely to be a corporate database.

Care teams are a set of caregivers who work together in care of patients. (See section 12.14.) Members of the care team may be informed of returning STAT or abnormal diagnostic test results via an “alarm” if an ordering caregiver associated with the care team is unavailable, or in addition to the ordering caregiver. A care team could also share clinical messages or e-mails associated with a set of patients and share responsibility for acting on these messages. Associated with the care team may be printer location(s) to send alarms. Characteristics of care teams could vary according to whether they work in the hospital, in an outpatient clinic or the ED. Sometimes order results and messages for a caregiver might more appropriately be sent to an associated caregiver, rather than a care team, for example, when the results for an outpatient come back the next day or when an outpatient care team has left for the day. See figure 13.13 for an ER diagram.

There may be many care teams working in the ED or an outpatient unit. The outpatient or ED patient registration might identify the unit where the patient will receive care. The particular care team for the outpatient would be the one in the unit to which the patient’s caregiver belongs. The caregiver’s order results or clinical messages for the patient would be sent back to the patient’s caregiver if the caregiver was available, and if the caregiver was not available, STAT or abnormal results and clinical messages coming back the same day could be sent to the caregiver’s care team if they were still scheduled; otherwise, they would be sent to a colleague, an associated caregiver.

In some HMOs there is an alternative description of an outpatient care team: Each member is permanently assigned to a care team for primary care, generally to the care team of the patient’s primary care physician. Whenever the patient comes in for primary care, there is an attempt to have the patient see his/her primary care physician or a member of his/her primary care physician’s care team.

Inpatient care teams are always non-permanent. Apart from the physician’s seeing the patient, the nurses and other caregivers are assigned to the unit, with each care team generally assigned for a separate shift within the unit. Through an admission or transfer, a physician may be associated with an inpatient as the admitting physician, attending physician, consultant, attending resident, hospitalist or personal physician. Associated with the inpatient may be an assigned care team, which includes nurses and physicians directly caring for the patient--the physician may or not be a member of this care team. STAT or abnormal test results for the patient are appropriately sent to this care team if the physician is not available so that members of the care team can take immediate action if required.

13.8.2.3 Patients, Encounters and Patient Lists

Patients

Patients are identified by a patient identifier such as a healthcare organization medical record number or national unique healthcare identifier. Information on the patient including addresses, phone numbers, birth date, sex and patient identifier are referred to as patient demographics information (see section 4.4.2). This should be a corporate database.

Encounters

An encounter is a patient coming to a healthcare organization to meet with a caregiver or a phone call which takes the place of an outpatient encounter. Types of encounters include an inpatient stay; outpatient visit; emergency department (ED) visit; a surgery; a phone call encounter; and a consultation where a second caregiver is asked to consult with a caregiver about a patient. A pre-admit will be considered to be a category of inpatient stay; an appointment, a scheduled outpatient visit for a patient with a resource, will be considered to be a category of outpatient visit. An observation visit where the patient comes in and is observed (such as for an impending delivery of a baby) and may be admitted or may return home; this will also be considered to be a category of inpatient stay.

In this book, an encounter is an important organizational entity relating patient visits, admissions, etc. and associated events such as orders. There are some events that should be recorded in the patient medical record which do not result in a formal encounter, or at least do not fit into ASTM’s definition of an encounter; see section 7.3.1. One example is a phone contact which does not take the place of an outpatient visit or result in a visit but for which documentation is generated and put in the patient medical record. For such events, it still might be useful have an encounter record on the database so events can be tied to it.

Encounters will have statuses. For example, statuses for inpatient stays include the following: pre-admitted, observation visit, admitted, discharged, transferred, case abstracted; while statuses for outpatient visits include the following: wait-listed, appointed, canceled, no-show, registered, visit completed. For more detailed information on encounters and encounter statuses, see section 7.4.1.

A set of encounters, orders and clinical pathways identified by caregivers as related to the same patient condition or medical problem (e.g., all outpatient visits, clinical lab tests, medications, labor and delivery, etc. related to a pregnancy) is called an episode. Encounter(s) leading up to an inpatient admission (e.g., an ED visit where the patient is discharged to the hospital) together with the inpatient admission can be identified as related and will be called a stay.

Patient Lists

A list of patients associated either with encounters, orders or phone calls is called a patient list. A patient list can be for a caregiver (a caregiver list) or for an area of a facility (an area list). See the ER diagram in Figure 13.14. Types of patient lists include the following:

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

· Outpatient List / Schedule that includes all patients with appointments or registrations for outpatient visits for a given caregiver or non-human resource. A schedule would also identify time where the caregiver is not seeing patients or a non-human resource is unavailable. Ideally, a schedule for a caregiver is for all locations in the healthcare organization where a caregiver works; for efficiency reasons, it may only be for the distributed facility group, with time outside the distributed facility group only showing that the caregiver is outside the distributed facility group.

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

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

· 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 (e.g., clean, dirty).

· Patient Panel listing all patients for which a caregiver is the principal primary care or other provider.

· Work List that lists for an ancillary department patients having orders to performed by the ancillary department (e.g., a clinical laboratory test to be completed, blood to be collected), together with details on the order.

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

· Caregiver-defined Patient List that is a list created by a caregiver user from selecting patients from other Patient Lists. A label may be attached to a Caregiver-defined Patient List.

Patients can be selected off a Unit Census to produce Nurse Assignment Lists assigning inpatients to nurses in the unit. These are types of Caregiver-defined Patient Lists, but are also types of Unit Census Lists because they are composed of lists of inpatients.

Orders may be sent from one caregiver to a second caregiver for a consultation, in which case the order will be put on a Consultation Request List for the second caregiver. Orders may be sent from a caregiver to a performing area, in which case the order will be put on a Work List. A Consultation Request List or Work List can be set up so that requests could automatically be transferred over to the resource scheduling system wait list, with the wait list request either being either accepted, later resulting in an appointment with the consulting physician, or denied.

Patient Lists may be for a specific date (i.e., date related) or for all dates (i.e., non-date related). Patient Lists may show or hide completed encounters. Some Patient Lists allow adding, deleting or modifying patient entries. See figure 13.15 for the default characteristics for the various types of lists.

Figure 13.15—Characteristics of Patient Lists

Patient List	Date Related / Non-date Related	Show/Hide	Add / Delete / Modify	Other
Outpatient List / Schedule	Date related always	Show appointments and outpatient registrations in the healthcare organization always	Not allowed	Besides appointments and registrations, the schedule will show (1) time where the resource is outside the clinics, (2) time where the resource is in a clinic seeing patients but where patients cannot
		except cancelled appointments. Show Cancelled appointments in the		normally be appointed (e.g., drop-in time), and (3) time in a clinic where the resource can have an appointment but none is scheduled. Time that is in transition from
		distributed facility group upon request.		appointed to non-appointed will also be shown with either (1) appointments remaining or (2) appointments cancelled. This is the only patient list recommended to go beyond the distributed facility group.
Inpatient List (Unit Census)	Default is non-date related	Hide always for non-date related. Show always for date-related; shown will be all patients in the hospital that day including those discharged.	Allows "Quick Admission" by adding a patient by entrance of patient identifier and bed; otherwise, add, delete and modify not allowed.
Inpatient Physician List	Default is non-date related	Hide always for non-date related. Show always for date-related; shown will be all patients in the hospital that day including those discharged that day.	Not allowed	The caregiver can also select to see discharged patients in order of most recently to least recently discharged.
Patient Panel for Personal Care Provider	Always non-date related	Show always	Not allowed if from other systems
Emergency Department Census	Default is non-date related	Hide always for non-date related. Show always for date-related; shown will be all patients in the ED that day, whether still there or discharged.	Allows entrance or modification of the caregivers seeing each patient.
Practitioner Defined List	Always non-date related	Show is default; hide upon request, hiding patients discharged from hospital or ED.	Add, delete, modify allowed.	The caregiver can assign a label to the list.
Surgery List	Always date related	Show always	Not allowed
Phone Call List	Always date related. For patients not yet called carry over to the next date.	For current date, hide phone call contacts and deleted patients, leaving patients to be phoned; optionally, upon show, also show phone call contacts. For previous dates, show only phone call contacts on that date.	Allow addition and deletion; allow identification of a phone call contact as an encounter.	The caregiver can identify those phone call contacts which constitute phone call encounters. The caregiver can assign a label to the list.
Consultation Request List	Non-date related	Hide appointed, book (wait) listed and deleted requests by default. Show all upon request.	Add and delete allowed	A Consultation Request List entry can be set up to be automatically sent to the schedule system to book an appointment or put the patient on a booking (wait) list for the associated caregiver.
Room Map	Non-date related	End the encounter for a deleted patient.	Add and delete a patient.	User can enter a patient identifier or drag over the patient's name from another Patient List for start of exam to put patient in room. Deletion results in ending the encounter.
Work List	Non-date related	Hide deleted requests by default. Show all upon request.	Add and delete allowed

It is expected that the Unit Census will include the patient identifier and bed location. Entrance of an additional patient identifier and bed location will be equivalent to a quick admission, creating an inpatient admission encounter. Other admission information is required to be entered by the ADT clinical system. Once the admission is returned from the ADT clinical system, the admission will be matched up with the quick admission encounter by patient identifier, with ADT information merged in with the quick admission information.

An Emergency Department List can be modified. It allows entrance, deletion and modification of any displayed caregivers associated with a registered patient.

A caregiver can put patients that he will call on his Phone Call List. After the caregiver calls the patient dispensing advice, a patient on the list can be identified as having a phone call contact with the caregiver, and, if applicable, having a “phone call encounter” with the caregiver. Patients can also be “removed” from the list

Patient lists within a local system will only display encounters occurring at facilities in the distributed facility group. An exception is an outpatient schedule that will show patients for the caregiver in all HMO facilities the caregiver works in.

Most patient lists are generated from encounters transmitted from other HMO clinical systems. A schedule also includes identification of time when a caregiver is not seeing patients. Methods of transmission of non-encounter information to the automated patient medical record system from the appointment system, such as schedule time not seeing patients, must be developed.

Selection of Patients

A patient can be selected by entrance of a patient identifier, by a Soundex search (a search for a patient based upon the sound of the patient’s name possibly along with other information such as sex and birthdate), by selecting the patient from a patient list, from a displayed e-mail or from a message associated with the patient, or from a displayed alarm or reminder associated with the patient.

Messages Related to Patients

A phone message or other message about a patient can be sent via a messaging system as described in section 7.7.3 from one caregiver to another (e.g., from an advice nurse to a physician). With the message, the sending caregiver can set a priority or “importance level” to be reported to the receiving caregiver along with the message (e.g., urgent, normal) that could also signify the maximum length of time given for caregivers to respond to the message and/or get back to the patient. The message can optionally be made part of the automated patient medical record, either by the sending or receiving caregiver. A message a caregiver receives associated with a patient can be selected by the caregiver with the same effect as having selected the patient from a patient list (i.e., selected so the caregiver can bring up the patient’s medical record without typing in the patient identifier). The receiving caregiver can respond to the message and close it out, or send the response to another caregiver to call back the patient; the caregiver calling the patient could then close out the message.

Normal e-mail should also be supported but with the additional capabilities to be able to also associate an e-mail with a patient and to be able to optionally include the e-mail in the patient medical record.

13.8.2.4 Patient Chart

See figure 13.16. The principal part of the paper or automated medical record for a patient are source documents (those entities in gray) such as H&P’s, progress notes, vital sign documents, clinical pathways, etc. and may include order, results of orders or addendums. In the automated patient medical record system many relationships may be set up, which may be useful in retrieving these documents.

Source documents will be categorized by the encounter they occur in. Encounters may be related by the type of problem, condition or concern they deal with.

Five types of documents can span encounters: defined outcome cases, chronic condition management cases, patient cases, clinical pathway and trend documents. Defined outcome cases and chronic condition management cases may include clinical pathway and trend documents.

Externally, document lists will tie together encounters and encounter documents. Document lists—see figure 12.16 in the previous chaper—will identify the type of each document, the facility location of the document, whether or not the document is in electronic or paper form, whether or not the document is archived, and other information to allow selection or filtering out of the document. Selection of an encounter, say from a clinical summary, could display (drill down to) a document list for a single encounter.

13.8.2.5 Orders, Results and Statuses

Orders

The system will provide ordering capabilities for caregivers listed in 7.7.2. It is expected that ordering capabilities would be provided for the following clinical systems:

Þ clinical lab orders through the clinical laboratory system (which will include microbiology, blood bank, standard and some anatomic pathology lab tests)

Þ outpatient and inpatient medication orders through the pharmacy system

Þ anatomic pathology orders through the anatomic pathology system

Þ consultation requests (referrals) to other caregivers and to performing areas inside and outside the ordering facility

Þ diagnostic imaging orders through the radiology system

Þ durable medical equipment (DME) through the DME system.

Besides simple orders ordering a single test, “complex orders” will be handled. Such orders will include repeating orders (e.g., q4h, every 4 hours), conditional orders (e.g., p.r.n., “as needed”) and order sets (e.g., CBC, “complete blood count”, which generates a series of blood tests).

Orders can be given order priorities, with priority from highest to lowest, for example, life and death, STAT, priority, routine.

Order Profiles

For each type and performing area location of an order, there must be information to interpret and validate the order, address the order to send it to the correct location and to control the types of caregivers who can initiate the orders. (See section 13.9 for security as related to some types of orders). It is proposed that for each type of order and performing area location of such an order there be an “order profile”.

Order Profiles will exist within each distributed facility group system to identify how to handle orders to and from the distributed facility group system and within the distributed facility group. There will be two types of Order Profiles, Remote Order Profiles and Local Order Profiles. In order to identify how to address orders to outside the distributed facility group, Remote Order Profiles will exist for medications, clinical lab tests, etc. to outside systems and to all caregivers outside the distributed facility group for whom consultation requests can be made. There will be a Local Order Profile for each local performing area and for each local caregiver who can receive consultation requests. The Local Order Profile for a performing area identifies the associated Work List; the Local Order Profile for a caregiver identifies the associated Consultation Request List. A Local Order Profile can optionally identify to automatically transfer over Work List or Consultation Request List entries over to the resource scheduling system for automatic scheduling of appointments.

Associating Orders with Encounters

Each order, where possible and applicable, will be associated with an encounter—either an inpatient admission, outpatient visit, ED visit, surgery, observation visit, or phone call encounter with a practitioner. During the order, the ordering caregiver will identify the associated encounter. The system will pass the order key to the ancillary system performing the order; it is the ancillary system’s responsibility to return the order key with an order status or order result.

Order Statuses, Results, and Addendums

Results and order statuses will be returned by the ancillary system to the ordering facility and will be associated with the order. Statuses for an order and returning results for clinical laboratory orders, radiology orders and clinical pathology orders, are the following: unknown status, service scheduled, service started, preliminary result, result final, result changed/amended, service canceled, service on hold, service continued. Results may be returned with various result statuses: panic or crisis, abnormal, out of range, normal.

The ordering caregiver and/or other identified caregivers or specific printers will receive a notification called an alarm if the results meet certain conditions (e.g., being abnormal, panic results, STAT, not being responded to by the ordering caregiver in a given amount of time, results not being reported back within a given amount of time). Caregivers who work together will be defined within the care team entity; the caregivers and printers to be alarmed for a particular ordering caregiver and location will be identified along with the situations under which they will be alarmed (see section 13.8.2.2).

The caregivers and printers receiving the alarm could be in the ordering facility or in other facilities. For example, the ordering caregiver could be alarmed in any facility where the caregiver is logged on. If the ordering caregiver is alarmed in a non-ordering facility, the caregiver will be re-alarmed when the caregiver logs on again in the ordering facility. From the alarm in the ordering facility, the caregiver could select the patient to see the detailed results.

The printer/caregiver alarm protocol would be controlled by code called an agent (see section 13.8.2.8 for a discussion of an order results agent). The protocol could include an escalation procedure to inform other caregivers or printers if the ordering caregiver or other caregiver does not respond in a given period of time, or the protocol could inform the ordering caregiver and other caregivers and printers simultaneously of the alarm. The protocol would also identify when alarmed results are not viewed within a given period of time and inform the ordering or other caregiver.

For medication orders, what may be considered equivalent to results are the recording of the administration of medications, for example, of medications administered in an inpatient unit as recorded on a Medication Administration Record (MAR), or administered in an outpatient clinic.

13.8.2.6 Clinical Summaries

See figure 13.17 for an ER diagram for Clinical Summaries.

A Clinical Summary is a summary of clinical information for a patient. There is a HMO Clinical Summary for a patient which will continually exist after initial creation at the central (e.g., HMO) level and summarize all the clinical information for a patient within the region. If there are CPR repositorie(s) with the HMO as a subscriber, an Outside Clinical Summary for the patient might instead exist with summary information collected from outside healthcare organizations included. Local Clinical Summaries, one for each distributed facility group system, that summarize all the clinical information for a patient within the local distributed facility group will exist after a patient encounter at the facility (and may continue to exist thereafter but not be up to date), and an Inpatient Clinical Summary will be created upon the patient’s admission, summarizing clinical information during the patient stay and, but last only as long as the inpatient stay. The Regional or Interregional Clinical Summary will automatically be copied to the distributed facility group system of the facility where there is an encounter and will be available to caregivers in all the facilities in the distributed facility group; a patient locator at the central level will be updated upon encounters and identify the location of the current/next encounter and thus the location of the Regional/Interregional Clinical Summary.

Previous to download of the Regional or Interregional Clinical Summary, the Local Clinical Summary will be up-to-date up to the last encounter in the Local Clinical Summary. Therefore, only information on encounters beyond that date need to be downloaded. If a Local Clinical Summary does not exist for some reason (e.g., its space was reused), then the whole Regional or Interregional Clinical Summary would be copied down.

A Local Clinical Summary will tie together all documents generated within a particular distributed facility group, including detailed orders and results, History and Physical, vital signs, SOAP notes, etc., with all documents being immediately available for display. The Local Clinical Summary will also have available the locations of all documents generated by other HMO facility group locations, and if there is a CPR repository, it will also have the locations of all documents from other healthcare organizations, up to the last encounter the Local Clinical Summary has recorded. Documents also may consist of summaries of encounters, called encounter synopses, either developed automatically by the system from other chart information or input by caregivers.

The Regional Clinical Summary will tie together all documents in the healthcare organization making up the automated patient medical record with identification of the facility locations of these documents; an Interregional Clinical Summary will locate documents in and outside the healthcare organization. Each of these documents would be stored at the facility and healthcare organization where it was created, and, if outside the distributed facility group, may be copied upon caregiver request or upon protocol to the distributed facility group of the facility where the Regional/Interregional Clinical Summary currently exists for an encounter. Synopses outside the distributed facility group will be automatically copied.

For a particular patient, the display of the patient’s Clinical Summary may be optionally tailorable by facility, unit, department, or individual caregiver (via agents, see Section 7.6). Information on the screen would contain enough information to identify the patient plus information selected from the following where available:

Þ patient demographic information

Þ a list of all encounters with diagnosis, provider and facility department location, with drill down to associated clinical information, including orders and results

Þ all orders and procedures, and results and alarms from orders, which will drill down to detailed information

Þ allergies and adverse reactions, allowing modification and addition (with future capture of allergies during the SOAP note interview)*

Þ immunizations, skin tests and reactions, allowing deletion and addition*

Þ significant health problems and date captured, allowing deletion, modification and addition (with future capture of problems during the SOAP note interview)*

Þ potential health problems to be studied and date captured, allowing deletion, modification and addition*

Þ family/genetic history, allowing modifications and additions*

Þ identified risk factors for diseases*

Þ medications with date, dosage, frequency and quantity, allowing modification and addition to identify all medications that the patient currently takes, including those dispensed at facilities outside the organization and including OTC medications, differentiating temporary from stable (long term) medications*

Þ alerts or reminders to identify specific patient conditions (e.g., wheelchair, difficulty speaking or comprehending English, visually impaired, violent patient, etc.)*

Þ a list of defined outcome cases and chronic condition management cases for the patient with a drill down to a list of treatment plans, defined outcome notes, clinical pathways, trend documents and other items related to the case and drill down to a list of encounters associated with the defined outcome case*

Þ a list of clinical pathway documents with drill down to care activities including orders and follow-up visits that may be automatically initiated or scheduled by the system*

Þ active patient cases*

Þ active trend documents

Þ referrals*

Þ assigned providers / case managers*

Þ a picture of the patient.

The item’s with *’s may be entered and updated by caregivers either through the clinical summary or other sources (e.g., problems, allergies, etc. may be enterable through the SOAP note).

All clinical summary windows can be increased or decreased in size at any time.

The Inpatient Clinical Summary would consist of enough information to identify the patient and areas containing information related to the inpatient stay, which may, for example, include

Þ patient demographics information

Þ working diagnoses

Þ significant health problems

Þ list of documents

Þ orders, procedures, results for the inpatient stay

Þ medications for the inpatient stay, including identification of inpatient medications actually taken as recorded in the MAR (Medication Administration Record)

Þ directives

Þ dietary requirements

Þ alerts related to the inpatient stay, such as an advance directive identified for the admission.

Þ drill down to flow sheets

Þ active cases

Þ active clinical pathways

Þ active trend documents

Þ important notes.

A caregiver at another location can consult with the encounter caregiver while the encounter caregiver is seeing the patient. The Regional/Interregional Clinical Summary would be copied for the consulting caregiver; the system would later automatically merge back any remote consultation encounter to the Regional Clinical Summary in the encounter facility. Through this mechanism, the patient could have remote access to specialized medical expertise at any location within the organization.

As a method to minimize network communication outside the region, an approach would be for the HMO to save chart summary information for a patient received from CPR and source document repositories on a designated local system, referred to as a virtual system, that handles out of region information for HMO patients. When CPR repository information is received for an encounter, associated source documents from source document repositories would be automatically ordered and when received, but stored on the virtual system.

When a clinical summary or associated documents are copied into a distributed facility group system for the encounter facility by caregiver request or by protocol, then they will be available for all facilities in the associated distributed facility group.

Within a local system, copies of the Regional or Interregional Clinical Summary and associated documents from other regions or organizations are always subject to deletion by a janitor agent (see section 13.8.2.8) based upon least recently accessed. Local documents and the Local Clinical Summary, or the part of the Regional/Interregional Clinical Summary listing the local documents, are never deleted, but local documents and parts of the Local Clinical Summary can be archived.

Within a central system, the Regional or Interregional Clinical Summary is never deleted, although, with a CPR repository, it could potentially be recreated.

During an encounter, documents would be tied to the Local Clinical Summary via the encounter. The encounter and documents locations would be downloaded for inclusion with the Regional Clinical Summary, where the documents would be associated with the encounter, and, if there were a CPR repository, they would be downloaded to the Interregional Clinical Summary where, again, the documents would be associated with the encounter.

13.8.2.7 Case Documents, Clinical Pathways, Episodes and Stays

Defined outcome Cases, Patient Cases, Chronic Condition Management Cases, Clinical Pathways, episodes and stays are all documents or entities spanning multiple encounters.

Defined Outcome Cases

See figure 13.18 and section 12.7.1 in the previous chapter. A defined outcome case identifies care decisions and encounters related to a treatment. A defined outcome case is composed of a treatment plan, addendums to the treatment plan and treatment notes, optional identification of clinical practice guidelines followed, clinical pathways to identify the treatment plan in detail, or trend documents. A defined outcome case occurs across multiple encounters. Each treatment plan, treatment plan addendum and treatment note is associated with the encounter where it is generated. At the beginning of a defined outcome case, expected outcomes are identified. After the treatment is complete, the final, actual, outcomes of the treatment may be identified and explanation of variances between the expected and actual outcomes.

Patient Cases

See figure 13.19 and section 12.7.2 in the previous chapter. A patient case are notes and other information for a case manager, making decisions on how to provide the most cost effective and appropriate care for the patient, including decisions based upon Medicare benefits. A patient case can consist of case notes, describing patient care decisions, zero or more clinical pathways, and possibly many other documents related to the patient’s case.

Chronic Condition Management Cases

See figure 13.20 and section 12.7.3 in the previous chapter. A chronic condition management case describes care for a chronic condition. A chronic condition management case can consist a treatment plan, treatment plan addendums and treatment notes, and optional identification of clinical practice guidelines followed, clinical pathways to identify the treatment in detail, trend documents. It can include case notes for the case manager and possibly many other documents for the case manager. A treatment can include a treatment plan and addendum(s) to treatment plans. It can have one or more treatment notes. Each treatment plan and note is identified during a particular encounter and thus must be associated with that encounter. Intermediate expected outcomes of the treatment can be identified. Intermediate actual outcomes of the treatment may be identified for periodic evaluation of the treatment of the chronic condition. Any variance between intermediate expected outcomes and actual intermediate outcomes can be identified.

Clinical Pathways (a.k.a. Critical Paths)

See figure 13.21 and section 12.7.6 in the previous chapter.

A clinical pathway identifies a standard of care for caregivers for a particular patient problem or condition with consideration of risk adjustments that also may be based upon patient psychological, health and social factors, family/genetic history, patient age, race and sex. Clinical pathways may exist for outpatients, inpatients or both. Clinical pathways may be used for treating illnesses or for managing health and wellness (and may then be known as health paths or life care paths).

A clinical pathway consists of a network-like structure, a clinical pathway template that consists of care activities ordered by various paths. A care activity may optionally involve on-line ordering, the scheduling of an encounter, or wait listing of an encounter. Paths may take an expected amount of time which may be expressed in terms of a probability distribution function, a mathematical function or set of tabular values identifying possible time values based upon analysis of similar care situations. Expected or final outcomes may replace care activities for the end nodes of the clinical pathway.

Caregivers seeing patients may select paths and connected care activities as actual paths through the template, after optionally modifying the clinical pathway template, adding paths and connected care activities. Future expected paths may be selected along with connecting expected care activities after optionally adding new expected paths and connecting care activities.

When an actual path and expected path differ with different care activities, a variance is recorded, identifying why the difference occurred. When an actual outcome does not match an expected final outcome, a variance is also recorded.

Episodes

Episodes are used to relate encounters, orders, clinical pathways and other documents to a particular patient problem or condition. For example, this might include all outpatient visits, medications, procedures and lab test orders, and labor and delivery related to a particular pregnancy.

Episodes, in the case of this book, are not usually explicitly identified but are related via defined outcome cases or chronic condition management cases.

Stays

A stay is a series of encounters that leads up to an inpatient stay. Examples are the following:

· the patient coming into the ER and consequently being admitted

· the patient coming in for an outpatient surgery that leads to complications that require the patient to enter the hospital

· a pregnant woman coming in for observation, but being admitted for labor and delivery.

Stays, in the case of this book, are not usually explicitly identified but are related via defined outcome cases.

13.8.2.8 Agents Implementing Business Policies

An Agent is code or tables, databases, interfaces between systems, or user interfaces that incorporates business policies into the system. An agent is a way of categorizing and separating out such a set of independent business policies so it can be easily changed. These business policies can be business policies related to the organization, region of an organization, distributed facility group, facility, department type, department, unit, caregiver job category or the individual caregiver. An agent performs a very specific function (i.e., service) and is triggered based upon a particular event or triggered to run at a particular time. As business policies change, agents are meant to change. Agents also include the administrative procedures of employees in implementing the business policy.

As stated in section 8.7, this book proposes that agents in some ways be treated like employees. An agent should be assigned a manager who understands the business policy and who, with other managers, periodically evaluates the business policy and determines if the agent should be changed.

Each such business policy and agent should be documented. See section 7.6 for more details.

The agent may be a company agent performing that function for the entire healthcare organization (a organizational agent), for a region (a regional agent), for a particular distributed facility group system (a distributed facility group agent), for a facility (a facility agent), for a department (a department agent), for a particular unit type (a unit type agent, for example, CCU), for a particular facility department type (a department type agent, for example, Pediatrics), for a nursing unit (a unit agent), or for an employee job category such as “inpatient nurse” or “outpatient physician” (a job category agent). A job category agent can be for the region, distributed facility group, facility, a unit or a department. Finally, an agent may be a caregiver agent, a type of agent set up for a particular caregiver, rather than for the company. See figure 13.22 for an ER diagram for agents.

See figure 13.23 for a complete list of the relative priorities of agents. A caregiver agent has priority over all company agents. Thus a caregiver agent written for a particular caregiver performs a duty for that caregiver (e.g., identifying the patient lists available to the caregiver) while that same duty for all other caregivers in the facility might be handled by a facility agent that performs the same duty, but in a different way, as all these other caregivers do not have a caregiver agent for that duty.

Figure 13.23—Priority of Agents

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

Examples of agents are the following:

· archive agent—an agent that controls archiving of documents. Documents older than an identified date would be archived, perhaps along with audit information on who accessed the document, and clinical summaries and patient lists would identify the associated documents as being archived and unavailable unless requested.

· order result agent—an agent that determines which results to alarm, the caregivers and printers who should receive the alarm, and any escalation procedure (e.g., the alarm is only sent to caregiver B if the ordering caregiver does not respond to the alarm in a given period of time). The order result agent will also keep track of whether or not the result associated with an alarm was viewed in a given period of time and if not, will apprise the appropriate caregiver(s).

· admission agent—an agent to control admission activities such as creating the Inpatient Clinical Summary and copying documents for the admission facility.

· discharge agent—an agent to control discharge activities such as destroying the Inpatient Clinical Summary.

· appointment agent—an agent to control appointment activities such as copying documents for the appointment facility.

· outpatient visit completion agent—an agent to control outpatient visit completion activities such as recording the completion of the encounter in the data base..

· electronic commerce agent—supports recording of medical services and orders for purposes of electronic commerce with outside vendors and with insurers.

· monitoring system filter agent—Filters out information from a particular monitoring system for inclusion in the chart--(However, it is uncertain whether this corresponds to business policies and where the filtering should occur, within the automated patient medical record system or within the monitoring system, {e.g., ICU system, Guardian Angel system}).

· consultant agent—an agent to control copying of the overall clinical summary and/or documents located at another facility

· backup agent—an agent to control backup of the entire system

· janitor agent—cleans up copied data and Regional and Interregional Clinical Summary information from a distributed facility group system, removing it when it is considered no longer useful. For example, the least recently used information may be removed, allowing more disk space for other information.

· patient list agent—identifies the types of patient lists available to a caregiver, facility, department, etc.

· clinical summary agent—identifies the format of the overall clinical summary and the Inpatient Clinical Summary for a caregiver, facility, department, etc. The format can be determined by the characteristics of the patient, with the format determined by factors such as patient age or sex (e.g., immunizations may only be displayed for children under 13).

· document location agent—an agent that controls the names of folders in the chart metaphor and what documents go in what folders.

· reference document agent—an agent that controls the health organization documents available to a caregiver (e.g., hospital policies, protocol and procedure manuals).

· data structure agent—an agent to control the relationship between a patient list or entrance of a patient’s identifier, patient demographics, the clinical summaries and the documents. For example, a regional or personal agent could be written to allow a caregiver to select a patient from an Outpatient Patient List and immediately display (i.e., drill down to) the Regional Clinical Summary. (Other connections would be determined by the system; for example, selection of an encounter on a clinical summary would in all cases drill down to the set of documents associated with the encounter.)

· security agent—a company agent to control access to organization information and specific documents as identified in section 13.9. The Security Agent would 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. The security agent might also provide greater access to information to specific types of caregivers or caregivers in specific departments (e.g., ED physicians and nurses might have access to psychiatry information on the patient, while caregivers in other departments, other than psychiatry, may not).

· remote security agent—another security agent to control which documents may be copied and sent to other organizations with business policies determined by agreements of the organization and its (outside organization or region) trading partners. See section 13.9.

· anonymous order agent—an agent to control the ability of caregivers to do ordering anonymously and to control view of such orders.

· public health agent—an agent to alert the organization and public health officials of usual increases in the incidence of influenza, specific bacterial infections or other public health problems.

· trending agent—an agent to identify persistent patient problems to a caregiver based upon information in the automated patient medical record (e.g., a cluster of respiratory infections, signs of potential cancer, etc.).

· QA / costing agent—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.

An agent may either run in the background or present a window to the caregiver to collect (parameter) information to control the agent. An agent may consist of code executed in one or in many different servers and in middleware.

Because agents may apply either regionally for all local systems or locally for all or part of a single local system, implementing agents via distributed objects may be applicable. CORBA and DCOM are such specifications for distributing objects across multiple nodes in a network (e.g., in the central system for organizational and regional agents and some job category agents and in the local system for other agents) [4,5]. See section 13.11.3.

13.8.3 Data Warehouses

Business analysis and other research databases are referred to as data warehouses. In this section a medical research data warehouse is presented and a financial data warehouse is presented. Each data warehouse is mostly or partially generated from patient medical record information.

For a data warehouse, a user should discover the relationships that are useful for the research the user is doing. Nevertheless, what is presented in this chapter are ER diagrams identifying some relationships that could be useful for medical research within a medical research data warehouse and some relationships that could be useful for financial research in a financial research data warehouse in an HMO. Discovering useful relationships in data warehouses is referred to as “data mining”.

13.8.3.1 Medical Research Database

Figure 13.24 describes a database that can be generated from patient medical records and can be used for medical research. It excludes patients’ social, family, environmental and genetic history which could be added to find associations between diseases and genetic and environmental factors.

Cases dealing with a specific disease or guideline can be identified. For each case, the outcomes can be determined, and the encounters making up the case can be identified. The patient associated with the case can be determined by selected users. The last medical history for the patient of the case can be determined.

For each encounter, the geographic location of the encounter can be determined and the medical history at the time of the encounter can be determined. For each encounter the medications, procedures, and diagnostic tests ordered during the encounter can be determined; alternatively, the encounters associated with a medication, procedure, or diagnostic test can be determined.

For each encounter, the clinicians see the patient can be identified.

The ER diagram implies that only the relationships shown are ones that analysts and researchers care about. Researchers care about all useful relationships. For example, outcomes of a particular disease using a specific medication can be compared against outcomes for the same disease and a different medication. As another example, outcomes for each physician performing a particular procedure, for example a coronary bypass operation, can be compared (e.g., patient mortalities).

13.8.3.2 Financial Database

Figure 13.25 describes a financial database to determine HMO costs and trends effecting costs, such as changes in membership growth and service costs. For example, identifying capitation fees that are consistent with changes in revenues, changes in membership, etc., can be determined.

Part of this information comes from the automated patient medical record system. This information is identified by the shaded entities. The remainder comes from other HMO systems, in particular from HMO financial systems.

Expenses and capital requirements (employee salaries and benefits, capital expenses, service expenses inside and outside) can be compared against revenues (capitation fees, copayments, insurance payments including Medicare, non-member payments).

Again the ER diagram describes a very limited number of relationships that analysts and researchers would care about. Many other relationships might be used or discovered. Such a financial data warehouse for a healthcare organization will likely collect information from more financial, clinical and other systems than mentioned here. See reference [6] on cost measurement and cost management in healthcare organizations for more information.

13.9 Security

13.9.1 Security Concepts for Electronic Medical Record Systems

This section describes security concepts in general for electronic medical record systems. The next section describes additional more specific security and security-related requirements this book proposes for our particular automated patient medical record system.

A software system is secure “if you can depend upon it to behave as you expect” [7]. And thus this book defines security as “safeguards applied to an automated system to insure that it behaves as expected”.

The Health Insurance Portability and Accountability Act of 1996 (HIPAA), a law governing the security of electronic medical record systems, is now being implemented by healthcare organizations [8]. HIPAA requires that various technical, physical and administrative security measures be combined to protect the privacy, integrity and availability of patients' medical records. These security measures would

· govern the transmission and accessibility of patient medical record information to individuals, organizations and to Medicare, disallowing access to those not authorized to view it

· protect against destruction of medical record information, and

· protect against the unavailability of systems providing access to medical record information.

Security concepts relevant to the implementation of HIPAA requirements, or to any comprehensive implementation of security in an automated patient medical record system and associated clinical systems, are listed in figure 13.26.

Figure 13.26—Security Concepts

Security Concept	Description	Examples of Techniques to Implement	Use in the Automated Patient Medical Record System
Person Authentication	For a person using a system, is he who he says he is?	Passwords, smart cards, biometric identification devices in comparison to stored information on each user; sign-on/sign-off, automatic logoff, digital certificates (server certificates) and digital signatures, firewalls	User sign-on and sign-off to system.
Application Authentication	For an application making a request for a service controlled by another application, possibly in another computer and organization, is the application the one identified and in the system and organization identified?	Kerberos, digital certificates (server certificates) and digital signatures, application to application controls (SSL/TLS), host to host controls (IPSec), IP/network address, firewalls	Communication between system and clinical systems, and especially between the system and the CPR and source document repositories.
Terminal or Other Hardware Device Authentication.	The terminal or other hardware device together with its location are identified.	Recording hardware identification of terminal, associated type of terminal, and allowable locations, DLC (Data Link Control) or MAC (Media Access Control) address, logical unit, firewalls.	Terminals and other devices in public areas vs. secured areas.
Authorization / Access	The information and services within an application system a person, another application system or device is allowed to access.	Access lists, LDAP	Access to information, secure terminals in secure departments (psychiatry, genetics), ordering capabilities (especially for narcotics), access to remotely located records.
Visibility	The functionality in an application system provided to a person.	Role-based access, person-based access	Functionality provided for meet caregiver's role or individual needs.
Administrative Procedures	Contingency plans for system emergencies; business policies on access control, employee termination procedures, physical protection of data, and consent for use and disclosure of information.	Overall site and organizational security policy based upon assess of risks, including documentation, data backup plan, disaster recovery plan, emergency mode operation, record of access, inventory, employee termination procedures (locks changed, userid removal, cards returned), new personnel clearance procedures and agreement signing, security incident procedures, user education, visual identification of patients, need to know procedures, procedures for loss of a computer or PDA, protection against social engineering, identification of why a system went down.	Operational policies supporting security.
Physical Safeguards	Security of physical computer systems and other equipment	Equipment in secure locations, access badges, cabinets with keys, physical attachment of terminals, identification of terminals and allowable locations, assessment of risks.	Protection of computers and other equipment.
Integrity of Data	The receiver has assurance that data sent is not altered and is from the said user or system.	One way hash with message digest, digital signature, replay checking, encryption / decryption, virus checking, intrusion detection systems, authorization and access control.	Communication between systems and/or people, including with the CPR and source document repositories.
Encryption / decryption	Conversion of plaintext to ciphertext / conversion of ciphertext to plaintext; may be combined with compression	Encryption algorithms, PKI, SSL/TLS, IPSec	Same as PKI
Public Key Infrastructure (PKI)	A set of capabilities to allow secure communication across a line by one party with a private key and the other with a public key.	Digital certificate, assymmetric and symmetric encryption, certificate authority, registration authority, public key, private key, digital signature, cross certification, time stamping, certificate revocation, trust mode., secure storage of private keys.	Communication between caregivers caring for a patient. Communication with CPR and source document repositories. Communication with insurers, including the federal government.
Confidentiality	The organization is assured that the data can only be seen by someone who has authorization to see it.	Authorization and access control to a document and to elements within a document when necessary, encryption, PKI, firewalls, intrusion detection systems	Privacy of medical record information of a patient.
Chain of Trust	For EDI, in which trading partners have specific agreements with each other, this chain of trust can be controlled by contractual agreements. For communication with outside healthcare organizations and medical providers, this chain of trust may have to be governed by laws and healthcare industry standards.	Contracts, service request authentication, cross certification, laws and industry standards	Communication with insurance and financial systems via EDI; communication with CPR and source document repository; request and granting of permission to copy or disclose patient records.
Identity Verification	The organization has assurance of the legitimate identify of each person, application, local device, and organization involved.	Registration authority; assignment of provider and patient identifiers by HCFA, biometric devices; hardware card identification of a device and a location	Recording passwords and unique identifiers of humans especially from biometric devices for later authentication; this information could be stored on smart cards secured by the user. Intelligent procurement of hardware. HCFA identification of healthcare organizations and of providers and patients.
Electronic signature	Identification of caregiver who created document which is equivalent of caregiver's signature	Undetermined, but most likely candidate is biometric information. See references [8,9] for requirements for an electronic signature.	Signing source documents; identifying caregivers doing ordering.
Nonrepudiation Evidence	The sender cannot deny sending the information or an electronic signer of a document cannot deny signing the document.	Electronic signature, digital signature, biometric system, smart card, intrusion detection devices, firewalls	Signing source documents; identifying caregivers doing ordering. Communication of medical information.
Availability of Service	The system is available for use when needed.	Load balancing, firewalls, fail-over recovery, clustering, parallel disk arrays, multi-processors, on-line backups and logging, intrusion detection systems, virus checkers, service level agreements, firewalls, ups (uninterruptible power supply)	Availability of automated medical record system and all clinical systems. Protection against bugs and other unintentional errors. Protection against attacks on systems.
Disaster Recovery	Information is available after a fire, earthquake, a major criminal act, or other major disaster.	Off-site duplication of information for backup. Backup computer systems.	Off-site duplication of medical record information for backup purposes. Backup computer systems for access to the medical record.
Auditing / Recoverability	Security-critical operations are recorded and information is recoverable.	Backups of information; log files; recovery system software; a procedure for emergency access to encrypted information	All systems.
Remote Access	Secure access from outside the healthcare organization; protection against theft	Remote access authentication and/or authorization systems that may include encryption and certificates, and logging (RADIUS, TACACS+), Virtual Private Networks (VPN), local system sign-ons, encryption of data on local databases	Remote terminals. Any access to the automated patient medical record system from outside the organization.
Request / Grant Permission for Medical Records	The creator (HMO or physician) and/or owner (the patient) of a source document can grant permission to an authorized party to copy or disclose the document, and authorized parties can request permission to copy source documents, perhaps with certain categories of permissions granted by policy	To be determined	Requests for medical records and their sending.

Authentication is the system knowing that a user, a terminal or other hardware device, or an application requesting a service of another application is who she, he, or it says it is. Authorization is the information and services within an application system a person, device, or another application system is allowed to access, which could be based upon the location of the device, while access controls determine how this information and these services can be accessed (e.g., this user can read, add, and replace this information, and this other user can only read it). Authentication and authorization for a person happens when the user logs on. Authentication of another application system requesting a service of the application system could occur just before the request or at log on of the user. Authorization for a terminal or other hardware device could occur every time it is used. Access control could be determined either at the time a resource is accessed or at log on of the user.

Visibility is the functionality provided to a person using the system, the user of the system. This visibility may differ depending upon the user’s role as a physician, nurse, medical assistant, etc. and may be tailored for a particular user.

Certain aspects of security occur outside the automated systems. Administrative procedures and physical safeguards must be set in the healthcare organizations using or having access to information in the system.

When communication occurs between two systems, two people, a person and a system, the receiver must have insurance that the data in the communication was not altered and is from the entity it is supposed to be from—that there is integrity of data. Such secure communications require a large set of technologies; one such set of technologies is called the public-key infrastructure. Part of this secure communication is encryption of data to change plaintext into ciphertext that cannot be easily read and decrypted back to plaintext; encryption is often combined with compression and decompression of the information to reduce the amount of data that needs to be transmitted.

Confidentiality is insuring that information, especially of medical records and other patient information, is only seen by the people authorized to see it. Medical records are both available inside the healthcare organization and outside the healthcare organization; therefore, confidentiality must be assured both inside and outside the healthcare organization. Within the healthcare organization, confidentiality is assured by access controls. Confidentiality externally is assured by keeping unauthorized people out of the system and by secure communication of the medical record to outside the healthcare organization.

Once a medical record has been sent outside the organization, then the healthcare organization no longer has direct control over the information. Confidentiality is dependent upon a chain of trust. For EDI, in which trading partners have specific agreements with each other, this chain of trust can be controlled by contractual agreements. For communication with outside healthcare organizations and medical providers, this chain of trust may have to be governed by laws and healthcare industry standards.

For authorization purposes and also for identification within medical records, system users, devices, computer applications, healthcare organizations, medical practitioners, and patients must be uniquely and conclusively identified. This requires identity verification that requires an infrastructure governed by trust, technology, laws, and industry agreements, that currently does not completely exist. HIPAA mandates unique physician and healthcare organization identifiers and has proposed unique patient identifiers.

Currently, paper medical records and medical orders must be signed by a physician and/or other authorized medical practitioner. The electronic equivalent of a physical signature is an electronic signature. Although an electronic signature for an electronic medical record has not been standardized and is no one particular thing [8, 9], an electronic signature must insure that the signer cannot deny signing the document, referred to as nonrepudiation. Nonrepudiation also applies to other senders of communications within the automated system, in that the sender cannot deny that he or she sent the communication.

Another aspect of security in automated systems is the insurance of the availability of service, that systems do not go down and that complete functionality of the system is available. This is particularly important for our system, where availability of the system is required at all times, for 24 hours 7 days of the week (24 x 7). Unavailability of the system or of parts of the functionality of the system may occur because of overloading of the system, program bugs, attacks by hackers, hardware failures—these and other causes of failures must be protected against.

Related to availability of service is disaster recovery. If there is a fire, earthquake, a major criminal act, or other disaster that destroys a chart room or computer systems, then there is a backup of this medical information and backup computer systems located off-site to the disaster. Disaster recovery is more feasible with an automated patient medical record, where the duplicate information is on kept on computer storage media, than it is with paper medical records, where medical records must be manually copied to paper or microfilm.

Security-critical events must be recorded so the causes of failures can be identified and recovered from. Auditing is recording security-critical events on a log file so an audit trail of these events can be recorded so the causes of the failures can be determined. When an automated system does go down under normal operations, then the system must be recovered to resume operation where it left off; this can be done by recovery procedures, such as restoring the system from backups or using a log fail to back out operations that caused a failure. For cases where an employee is unavailable and the employee has encrypted information, such as on disk, there must be a way for the healthcare organization to access the information in emergency situations.

To enable caregivers and others to better perform their jobs, remote access to the automated systems may be required. This requires attention to security threats. If a terminal is stolen, you do not want the thief to have access to patient information on the system; information can be protected by requiring sign-ons to use the system and by encrypting database information so a disk cannot be removed and read on another machine. Secure remote access to the automated patient medical record system for dial-in connections or direct connections can be assured by use of remote access authentication and/or authorization systems that may include encryption and certificates, and logging (RADIUS, TACACS+); the Internet could be used as the network with encryption of transmissions through use of virtual private networks (VPNs).

When it comes to medical records, special consideration must be given to both administrative and technological methods of requesting permission to copy medical records or disclose information in medical records, and of granting permission to do so.

Security measures for an automated patient medical record must provide a balance between many things, including the following: patient privacy; healthcare organization privacy; caregiver access to medical records; government and regulatory organization requirements; and costs and cost savings to the healthcare organization and patient.

13.9.2 Additional Security Concepts for Our Proposed System

This section identifies some ideas on additional security concepts that may be appropriate for our proposed automated patient medical record system.

Identifying a user, as stated in the previous section, is called authentication and what information a user can access is called authorization. A user would be able to sign on to the system at each distributed facility group computer at which the user has a user account. In the proposed design, a caregiver will have a user account for every distributed facility group that includes a facility where the caregiver works.

One business requirement stated earlier was to provide quick log-on and sign-off of the system, so the caregiver spends very little time logging on and off the computer. Possible log-on approaches, in addition to the usual on in most systems now--the keying in of a password on the keyboard, are scanning of the caregiver’s identification badge or smart card or user of a biometrics recognition device, such as a fingerprint reader (see section 17.2.6 for more discussion of this subject).

It is proposed that there be a time-out period after non-use of the terminal, with blanking of the screen. The system would continue where the user left off after the user logged back on.

Associated with a terminal would be a terminal profile. The terminal profile might define a logon group, a group of users associated with the terminal who are allowed to log on.

Associated with all user accounts will be security information in an area called a user profile with other user information probably coming also from a database on caregivers. The user profile is expected to contain the user’s password and security codes that identify which special security access the user has. The secure codes will be used to control the visibility of information by department, unit or by individual document, with one or more secure codes optionally associated with each department in each facility, each unit in each facility and each document in patient clinical information. Also the user profile will identify the job category(-ies) of the caregiver and thus identifying standard ordering and other activities, and possibly information to enable automatic system logon to other HMO clinical systems if the user logs on to the automated patient medical record system.

Associated with a physician may be a DEA (Drug Enforcement Agency) number to identify that the caregiver can order narcotics. Alternatively, the DEA number may come from a credentialling system that records HMO information for the credentialling of a provider, including licenses (such as the DEA license), medical school and other degrees, insurance, board certification, certificates, hospital privileges, specialties and sub-specialties.

Associated with a nurse practitioner may be a drug “furnishing number” that allows the NP to order drugs and devices in accordance with standardized procedures and protocols approved by a supervising physician. Alternatively, this could come from the credentialing system.

A secure code within a user profile may also be used to control a caregiver’s ability to order a specific test or specific procedure that will be done anonymously (e.g., Alzheimer’s testing, HIV testing, therapeutic abortions). Only caregivers that the caregiver has pre-identified will be able to identify the patient associated with such a test or procedure. Such an order will be referred to as an anonymous order.

If a user logs on to a second distributed facility group system concurrently with logon to the first on the same computer, he will not have to re-enter his password. The previously entered password will be carried over.

At any time including user logoff, the system will optionally allow the user to set a bookmark related to a user account to identify where he left off and to return to that exact location—patient list, clinical summary for a particular patient, or document list with selected documents for a patient—upon user logon. This is similar to a snapshot, which allows return to information for a particular patient.

The system will also audit viewing of all documents, results and alarms, recording who saw them.

Further, an electronic signature mechanism [10] will be provided for all documents where the equivalent paper document requires a caregiver signature. This electronic signature must be legally valid in all states in which the associated document could be viewed; the electronic signature will be transmitted with the document. Control over which documents can be copied outside the organization or region will be controlled by agreements between the trading partners.

The system will enforce the data integrity of a completed document: after the editing process and/or electronic signature, no information in the document may be lost or altered in any way.

Mechanisms for handling caregiver collaboration on the same patient encounter must exist. This may include two or more caregivers seeing the patient one after the other or together. It may also include a caregiver being consulted during the patient encounter, which may involve a caregiver who does not work within the distributed facility group of the patient encounter—this is a case where the consulting caregiver may not have a user account within the distributed facility group of the patient encounter. This latter situation will be referred to as a “remote consultation” and is discussed in section 13.10.

Based upon the existence of a central system and local systems, figure 13.27 identifies a proposed scope of visibility of various types of information within the proposed system. Patient lists, clinical summaries and documents are available for concurrent view by multiple caregivers.

Figure 13.27—Proposed Scope of Visibility of Information

Data Item	Scope of Visibility
Patient Demographics	Stored centrally. Available within each distributed facility group.
Patient Lists	Distributed facility group of the associated encounters, except for schedules which are centrally located and exist whereever the caregiver works.
Local Clinical Summary	Distributed facility group
Overall / HMO Clinical Summary (dependent upon whether the HMO keeps track of outside HMO encounters or not)	Central system and distributed facility group for the facility for an encounter. The Overall / HMO Clinical Summary will automatically be transferred over from the central system to the distributed facility group of another facility based upon a later encounter taking place or upon a future encounter scheduled with the previous encounter being identified as being complete. Also, as a "consultant", a caregiver with another distributed facility group or an Agent can request a copy of the Overall / HMO Clinical Summary.
Inpatient Clinical Summary	Distributed facility group
Source Documents, including Order/Result	Distributed facility group. If an encounter occurs at a facility within another distributed facility group, a caregiver or agent can request a copy of a non-local source document referenced in the associated Regional or Interregional Clinical Summary.
Encounter Synopses	Encounter synopses will be within the distributed facility group and copied after the encounter to the central level. Upon a new encounter, the synopses, if necessary, will be sent down to the distributed facility group of the encounter.
Translation Information	Translation Information will be sent over with a copied source document from another healthcare organization.
Data Dictionary	Stored at the central level. Available at each distributed facility group system.
User Profile	The distributed facility group where the caregiver user has a user account.
Terminal Profile	The distributed facility group of the facility where the terminal is located.
Order Profile	Are specific to a distributed facility group. Remote Order Profiles for a remote order in the distributed facility group of the ordering facility must be matched by a Local Order Profile at the performing area distributed facility group.

During a patient encounter in a facility in one distributed facility group, clinical summaries and documents may be copied to another distributed facility group system to enable a consulting caregiver to provide advice on the patient. See the next section on interfaces under the title “remote consultation”.

13.10 Interfaces

The next section describes the basics of healthcare network communications and interfaces. This section describes proposed interfaces for our automated patient medical record system.

These proposed interfaces include the following: (1) interfaces with other clinical systems within the healthcare organization, (2) interfaces between the central system and local systems, and (3) interfaces with systems outside the healthcare organization are presented in this section. Where possible all network communication of information will be through messages in HL7 format.

13.10.1 Interfaces Between the HMO System and Other HMO Clinical Systems

· Clinical information received from other clinical systems through the central system: Other clinical systems may send an encounter or encounter status change, send back an order status change, result and/or alarm associated with a previous order, send back a clinical system generated order as a result of another order (e.g., the clinical laboratory may redo a test with results way out of range assuming a piece of equipment is malfunctioning), send a patient demographics update to the central system. Communication is via HL7. See figure 13.28.

An encounter or encounter status change will be sent to the encounter facility and any other local system computer having a facility with an outstanding encounter. Outpatient appointment or outpatient visit encounters are sent to every facility where the associated caregiver potentially works in order to generate the outpatient schedule with the associated facility group system.

A “discharge” encounter status will close the associated outstanding encounter, and will inform the central system to expect the complete patient medical record encounter information.

An order, change in order status or results will be sent to the ordering facility. Any change to patient demographics will be updated in all local systems.

· Clinical information is sent to a local system from other local clinical systems: Clinical systems directly connected to the local system may send an encounter or encounter status change, send back an order status change, result and/or alarm from a previous order, send back a clinical system generated order as a result of another order (e.g., the clinical laboratory may redo a test with results way out of range assuming a piece of equipment is malfunctioning), or send a patient demographics update. Communication is via HL7. See figure 13.29.

An encounter or encounter status change will be sent to any other local system with a facility with an outstanding encounter. Outpatient appointment or outpatient visit encounters are sent to every facility where the associated caregiver potentially works in order to generate the outpatient schedule with the associated facility group system.

A “discharge” encounter status will close the associated outstanding encounter, and will inform the central system to expect the complete patient medical record encounter information. Any change to patient demographics will be sent to the central system and updated in all local systems.

· Local system clinical information sent to other clinical systems Notification of an admission (quick admission) directly through the local system (e.g., adding a patient to the Unit Census) will be sent to the ADT system. Notification of the completion of an outpatient clinic visit (e.g., the patient is removed from a room map) will be sent to the Registration system. Patient demographics changes at the local level will be sent to other HMO clinical systems. Communication is via HL7. This information is also optionally saved on a central database.

See figure 13.30 for the case where the clinical system has an interface through the central system. See figure 13.31 for the case where the clinical system is directly interfaced with the local system.

Instead of an admission being identified through the ADT system, an admission, a “Quick Admission”, can first be identified through the automated patient medical record system through adding a patient to an Inpatient Census, Patient List or Inpatient Unit Room Map. In such a case, ADT would be informed of the admission after which further information on the admission would be collected through ADT.

A completion of an outpatient visit will mark the outstanding encounter as closed, and will inform the central system to expect the complete patient medical record encounter information.

A change in patient demographics in a local system will be sent through middleware to other HMO clinical systems. (The patient demographics change in turn will be sent back to the local systems from the other clinical systems; see figure 13.28.)

· An order being made via the central system: A caregiver can send an order to be executed to an ancillary system via the central system, such as a medication order to the pharmacy system; see figure 13.32. One caregiver can also make a consultation request to a second caregiver in a facility in another distributed facility group, placing the order on a Consultation Request List for the second caregiver, or the caregiver can send an order to a performing area in another distributed facility group, placing the order on a Work List in the performing area; see figure 13.33. Orders might also be saved in the central database, including those internal to a local system.

A completion of an outpatient visit will mark the outstanding encounter as closed, and will inform the central system to expect the complete patient medical record encounter information.

· An order being made through a local clinical system: A caregiver can send an order to a local ancillary system to be executed, such as a medication order to a local pharmacy system; see figure 13.34.

· Interfaces to load and update local HMO translation/validation information:
In order for local systems to do ordering, they must have information to validate or translate the ordering information including clinical lab test directories and drug formulary information. Note that there are three potential alternatives for storage of HMO validation and translation information from other clinical systems: Alternative one would have the information only reside in a clinical system, and not the automated patient medical record system, in which case the clinical system, rather than the automated patient medical record system, would be doing any translation or validation of automated patient medical record information; this would save on costs of shipping the information to the automated patient medical record system but require information to be translated or validated to be shipped to the clinical system with a response back. Alternative two would have the information duplicated in each applicable distributed facility group system; this would have the greatest efficiency in doing translation and validation of automated patient medical record information but would require the shipping of the checking information to each of the distributed facility systems. Alternative three would be to have the clinical information reside in the central system; this would allow the information to only reside in the central system and not each of the distributed facility group systems, but would require shipping down of clinical information and would provide somewhat less efficiency than alternative two in doing any translation or validation of automated patient medical record information. Alternative three is assumed in figure 13.35.

Interfaces to load and update this translation/validation information may either be on-line interfaces shown by Path (1) or off-line batch interfaces shown by Path (2). These interfaces may include the following: (1a) on-line initial load of information; (1b) on-line update of information, such as downloading a newly identified caregiver in the other HMO clinical systems; (2a) initial load through a batch job, such as one to read the First Databank Tape for medications in a drug formulary, or one to load resource information. (2b) Periodic update through a batch job, for example updating CPT4 and ICD9 code lists at the same time they are updated in the other HMO clinical systems. See figure 13.35. So that current and historic clinical information can be translated properly, translation/validation information must be kept up to date at all times with the same information in the other HMO clinical systems and historic translation/validation information must be kept.

· Schedule updates or changes sent from the appointment scheduling system: Because the patient list for outpatients should consist of a schedule not only including a list of patients with appointments and registrations for a date but also time when the caregiver is unavailable, still open for appointments or outside the HMO, there must be an interface to the appointment system to retrieve this caregiver time information. These processes could be similar to validation/translation information updates and changes shown in figure 13.35. It is proposed that such schedule information for each caregiver be sent to the central system from the appointment system at the beginning of the day.

Whenever there is maintenance of the schedule, the changed schedule information would be sent to the central system from the appointment system. See figure 13.36. A distributed facility group system could use this schedule information and merge it in with appointments and registrations in each distributed facility group where the caregiver could potentially work.. A schedule would exist at any facility where the caregiver would potentially work.

· A request for an appointment, returned appointment times and booking selection: Whenever a caregiver books an appointment through the automated system, this appointment request would be sent to the appointment system. Appointment time that is available, if any, would be locked by the appointment system and returned to the automated system for display. The caregiver would select one of the available appointments, with the selection being returned to the appointment system and notification to unlock the other selections. Optionally, the search could be continued for further appointment selections from which the caregiver could make a choice of which one to book. See figure 13.37.

13.10.2 Interfaces Between the Local and Central Systems

· A Clinical Summary transfer request upon a new encounter sent to the central system: Upon receiving notification of a new encounter (such as an appointment, preadmission, admission without preadmission) from an HMO encounter clinical system, the central system will cause the Clinical Summary for the associated patient to be sent to the system handling the encounter facility and mark the encounter as an “outstanding encounter”. See figure 13.38.

Note that the distributed facility group of the encounter facility may already have a copy of the Clinical Summary together with associated documents. Only the encounters of the clinical summary that the local computer does not already have will be sent. The local computer must inform the central computer of the last encounter it has for the patient. Note that source documents for previous encounters may be resident in the local system or previously requested from another system and already exist. Also agents on the local system may also automatically request source documents.

· A Clinical Summary transfer request upon a new encounter sent to a local system: Upon receiving a new encounter from an HMO encounter clinical system, a local system will send the encounter to the central system along with the last encounter in its current Clinical Summary for the patient. See figure 13.39.

The central system will send the Clinical Summary for the associated patient to the computer of the encounter facility. The central system will mark the encounter as an “outstanding encounter” in the central database. And the encounter will be sent to any other local system with a facility having an outstanding encounter.

Note that the distributed facility group of the encounter facility may already have a copy of the Clinical Summary together with associated documents. Only the encounters of the clinical summary that the local computer does not already have will be sent. Note that source documents for previous encounters may be resident in the local system or previously requested from another system and already exist. Also agents on the local system may also automatically request source documents.

· A “remote consultation”: A caregiver at another facility in a different facility group of the encounter can provide consultation advice for another caregiver who is seeing the patient—this will be referred to as a “remote consultation”. The consulting caregiver can request a copy of the Clinical Summary from another distributed facility group system for purposes of providing consultation advice to the caregiver in another facility. See figure 13.40. The consultation will be identified as an “outstanding encounter” with the encounter being recorded on the central and consulting facility clinical summary.

· A document copy request: This is a request to receive a copy of a document referenced through the (Inter-)Regional Clinical Summary but located at an HMO facility handled by another distributed facility group system. (Translation information might be copied over with the document, especially, when the document comes from a system in another region or from an outside organization, such as from a reference laboratory.) See figure 13.41.

· Creation and Updating of Data Warehouses: Batch processing could collect new information, perhaps daily, from local system clinical summaries and source document databases and from other HMO systems. This information could be merged and loaded to create or update the data medical resource and financial warehouses identified in section 13.8.3.

13.10.3 Interfaces with Outside HMO Systems

· The HMO being informed of a visit outside the HMO: Upon HMO subscription to CPR repositories for HMO patients, possibly via a patient registry, the HMO is informed of an HMO member’s outside healthcare visit. See figure 13.42.

· An HMO requesting CPR repository locations for new HMO member or visiting non-member: Upon HMO identification of a new member (perhaps from the HMO membership system) or upon identification of a non-member visit to the HMO (perhaps from the HMO appointment or registration system), the HMO makes a request of the patient registry for CPR repository locations containing patient encounter information. See figure 13.43.

· An HMO requests and receives CPR repository information: Request CPR repository information for a patient encounter for storage with the clinical summary to produce an Interregional Clinical Summary and possibly sent to a local systems where there are upcoming encounters. See figure 13.44.

· An HMO requests and receives source document repository information: Request source documents for an encounter from a source document repository. Save source documents on the central system or on a virtual local system. See figure 13.45. Note that a source document that is in some other healthcare organization’s chart room, rather than a source document repository, may have the capability of being electronically ordered; either a mechanism to transfer the chart information electronically or to send a copy of a paper chart by mail may be set up by the other healthcare organization; see subsection labeled “An interregional document copy request”.

· Patient encounter information sent to the CPR repository and other local systems with outstanding encounters after an encounter: After an encounter, the CPR summary of encounter information, patient demographics information, and the locations of source documents created during the encounter should be sent to the CPR repository. Information is stored in a queue and possibly resent if acknowledgment is not received. See figure 13.46. This information should also be sent to all distributed facility groups where there is an outstanding encounter to keep (Inter-) regional clinical summaries at these locations up-to-date.

As described in section 7.7.1 and shown in figure 7.7, it is proposed that patient encounter information put into the CPR (and into clinical summaries) be translated to data in national standard formats.

· An interregional / outside HMO document copy request: Request a copy of a document outside the current region of the HMO or outside the HMO referenced in an Overall Clinical Summary. (Translation information might be copied over with the document, especially, when the document comes from outside the HMO.) See figure 13.47.

· An interface to an outside agency to assign or look up a Universal Patient Identifier for a patient or another identifier such as one for a healthcare provider; interfaces to periodically download and update standard identifiers off-line: The CPR repositories and source document repositories, as well as possible clinical summaries, will reference a patient by a Universal Patient Identifier. A Universal Patient Identifier for EDI has been mandated by law. A possible mechanism for looking up and assigning such a Universal Patient Identifier is presented here.

If there is a new patient to the HMO, the HMO should have the ability to do an inquiry through a remote “assigning authority” 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 (see figure 13.48). Transmitted to the assigning authority will be a set of patient identifiers that together could uniquely identify the patient (e.g., last name, date of birth, sex, mother’s maiden name, etc.); although other organizations use the term in a different way, I will refer to this set of identifiers as the “Master Patient Index” for the patient.

Other national identifiers have also been mandated will require similar on-line inquiry and assignment. These include a healthcare organization site identifier or healthcare provider identifier. Other standard data elements not requiring immediate update might be handled by tapes sent from assigning organizations.

· Source documents periodically archived to the Source Document Repository: As described in section 7.7.1 and shown in figure 7.7, it is proposed that, after an encounter, that source documents and associated encounter information be sent to a source document repository. See figure 13.49. The (new) location of the source document would also be recorded in the CPR repository and central system to be store with the encounter information. The source document could be saved in a queue and possibly resent if acknowledgment of receipt is not received. Agents within the HMO system could schedule and control archiving of source documents. Translation information, to translate from the local to national data standards, would be created during the documentation or ordering step and included with a source document sent to a source document repository.

· Clinical practice guidelines from Clinical Practice Guideline repositories: New clinical practice guidelines for the HMO could be saved in an HMO Clinical Practice Guideline Repository; a clinical practice guideline might later be updated with the previous version also being kept. National Clinical Practice Guideline Repositories might also exist. The automated patient medical record might reference a clinical practice guideline by guideline identifier, repository location and document creation date. A guideline could then be later retrieved using these keys.

13.11 Network Communication Techniques

This section describes network communication techniques that may be useful for implementation of interfaces in the automated patient medical record system. These techniques include the following:

· message queues

· remote procedure calls (RPCs)

· object request brokers (ORBs)

· mobile code

· interface engines

· clustering.

System software that handles such network communication is termed “middleware”.

A standard format for network communication with healthcare computer networks is HL7. This is also described in this section.

13.11.1 Message Queues

See Figure 13.50(a).

Rather than requiring a receiving computer system to be up in order to send a message, a message could be put on a queue on the sending system and sent to a queue on the receiving system when the receiving queue is available. The receiving system could either periodically check the receiving queue for messages or be informed by the queuing system of a message and then pick up the message.

Message queues are particularly applicable when it is extremely important that a communication between two systems not be lost. This applies to orders sent from the automated patient medical system to ancillary systems.

The most used message queuing system software is IBM’s MQSeries [11].

13.11.2 Remote Procedure Calls (RPCs)

See Figure 13.50 (b).

A procedure is a block of code which may be initiated (called) from many different programs with return to the next location in the calling program after completion. Remote procedure calls (RPCs) behave like local procedure calls except that code may be in two or more different computer systems in a network, rather than on one. RPCs insulate the application programmer from the details of the underlying network. RPCs require synchronous connections between systems (i.e., they require the other system to be up).

If the system initiates an on-line query where the information comes from a clinical system other than the automated patient medical record system, an RPC would be the appropriate vehicle. For example, the system might initiate an on-line query via an RPC to receive a provider schedule from the resource scheduling system, pick up patient benefits information, or locate or request patient charts.

13.11.3 Object Request Brokers

See Figure 13.50(c).

Object request brokers (ORBs) permit objects to transparently make requests to, receive responses from, other objects, which may be local or remote. The client making the request does not know or care about how this communication happens, how the objects are activated or where the objects are.

The concept of an object is presented in section 13.14.2.

Once a client makes a request for a service on an object, the ORBs are responsible for all the tasks required to find the object implementation in the network, to prepare it to receive the request and to finally transmit the request. It is also responsible for communicating the results to the requester. ORBs can be implemented (transparently) via RPCs or even by messaging queues.

Objects and ORBs would be particularly suited to handle agents. Agents apply at different levels (e.g., an agent may apply organizationally, regionally, for a facility, for a particular caregiver). The agents could be stored centrally or locally depending upon where they apply.

Commercial methods for implementing ORBs are CORBA[4] and DCOM [5].

13.11.4 Mobile Code and Mobile Agents

Mobile code is a program traveling on a heterogeneous network from one computer to any other, executing on the destination computer [12]. The most well known programming language for such programs is Java.

Such a program is usually run under a browser or a virtual machine interface with the program being interpreted rather than being run as a compiled program. This allows the same program code to be run on any computer without consideration of the type of processor being used (Intel, IBM 360, Sun Solaris, etc.). Also, the program code does not have to be permanently stored on the computer where it is run, but can be shipped down when needed, alleviating problems of having to copy the program to many different computers when there is a new version of the program.

The principal disadvantage of mobile code, such as an automated system written in Java, is that the code has to be shipped down over the network from a host computer permanently storing the system to the computer where it is run, with a resulting long wait by the user until the automated system is loaded. Loading of the programs making up the automated system on a local computer is likely to be done each time the user logs on, and thus a user would have to wait a significant period of time after he logs on to his computer before he could run the system.

Another disadvantage of mobile code is that interpreted programs generally run much slower than compiled ones.

Rather than using mobile code for an entire automated system, mobile code could be used for execution of small programs. For example, mobile code could be used for implementing an agent, producing a “mobile agent”. For example, one copy of a regional agent could be stored on the central computer and shipped down when necessary to any local computer when needed to execute the associated business rule on the local computer. In such a case, the time to download the program on the network would not be a factor.

13.11.5 Interface Engine

Interface engines have been developed for the healthcare industry. An interface engine is a middleware product, usually implemented on a dedicated computer, that receives, logs, optionally translates and forwards messages between application systems running on different systems, guaranteeing their delivery even though the receiving system may be temporarily down. Since interface engines are developed for the healthcare industry, a protocol almost universally supported is HL7.

For example, the ADT system might send admissions to the interface engine in HL7 format. The interface engine could send the admission on to both the pharmacy system and clinical laboratory system, also in HL7 format, so these systems could later match up paper orders with the admission and patient’s bed location. At the same time, the interface engine might translate the HL7 admission message and put the admission on a database for the automated patient medical record system, so the automated patient medical record system could match up a later order with the admission.

13.11.6 Health Level 7 (HL7) Network Protocol

The International Organization for Standardization (ISO) and other organizations have defined models for network communication. Various “layers” are used for different purposes, description of hardware, routing, connections, data integrity, etc. Layers are striped off at various points. Layers, except for the innermost layer, consist of header and trailer data. Seven layers are defined by the ISO. Usually, not all layers are used; for example, TCP/IP uses 4 layers.

The innermost layer is called the application layer and provides the data for the software application using the network communication. For health care communications, especially between commercial clinical systems, Health Level 7 (HL7) application messaging protocol has been defined.

Version 2.3 of HL7 supports messages in the following categories:

· Patient Administration (e.g., admission, discharge, transfer, register)

· Order Entry (e.g., diet order, supply order, pharmacy order)

· Financial Management (e.g., diagnosis, procedures, guarantor, insurance)

· Observation Reporting (e.g., narrative reporting, waveforms reporting)

· Master Files/Shared Dictionaries (e.g., clinical test directory update, drug formulary update)

· Medical Records/Information Management (tracks documents or entries that have been or will be transcribed)

· Scheduling (e.g., appointment making and inquiry about scheduled activities)

· Patient Referral (identifies referrals from one healthcare practitioner to another)

· Patient Care (tracks acute or chronic medical problems and associated goals, roles, clinical pathways and variances).

Version 3.0 of HL7 adds support for ORBs and EDIFACT.

An example of a series of HL7 messages between an ordering system and a pharmacy system are as follows:

· a new reoccurring medication order for an inpatient is sent to the pharmacy system from the ordering system

· a filler ID is passed back from the pharmacy system to the ordering system

· a message is later passed back to the ordering system that the medication has been administered

· the ordering system later sends a message to discontinue the order.

13.11.7 Clustering: Fail-over Recovery and Load Balancing

There are two potential problems with network connections: (1) A connection can go down, thus potentially causing the system to fail, and (2) a connection can be overloaded, thus potentially causing the system to slow down. In section 13.12.1 we presented one approach to handling a connection that goes down, a message queue. In this section we explore an approach that handles both connections that go down and those that are overloaded, clustering.

A cluster is a group of computers working together to share resources or workload. Figure 12.22 in the previous chapter shows an example of clusters and the use of clustering. A cluster enables fail-over recovery, meaning that when the primary computer (server) goes down, a backup computer (server) automatically takes over. A cluster enables load balancing, distributing processing and communications activity evenly among computers in a cluster so no computer is overloaded. Clusters also allow one computer to be brought down, with the other computers taking over the load of that computer that is brought down.

Clustering should be used anywhere where there is the possibility of a single point (of) failure (i.e., where there is a network connection that, if it went down, would cause the system to fail in some way), and where it is critical that the system does not fail.

As examples, clustering applies to web servers and to interface engines, with information being sent to a secondary web server to handle a web connection when the primary web server goes down, or to a secondary interface engine to handle an HL7 connection when the primary interface engine goes down.

Clustering could apply to pharmacy systems receiving medication orders. If a pharmacy system went down, the order could automatically be sent to a different pharmacy system to fill the medication order.

13.12 Component Adaptability

Component adaptability is use of various strategies to procure, develop or structure a system or component of a system so that the system or component can more easily be replaced in the future by an improved system or component. These strategies include the following: (1) following an open architecture for software and hardware and following healthcare data processing standards so an improved system that follows the same standards can replace the previous system using those standards; (2) using a system that is independent from other systems (e.g., an e-mail system that can be replaced by another independent e-mail system); (3) designing a component of a system--say Component A, a user interface--such that it shares data with the remainder of the system but is otherwise independent from the rest of the system, thus allowing Component A to be replaced by Component B, a different user interface, if the replacing component (Component B) produces the same data as Component A; and (4) using periodically renewable, instead of very long term, contracts for vendor systems, thus not being monetarily forced to use a vendor system that should be replaced.

For example, the use of HL7 as a healthcare network communication standard opens up the possibility of having replaceable systems and supports component adaptability--see figure 13.51. If each of the clinical systems connected to the automated patient medical record system uses a standardized HL7 connection with the automated patient medical record system with very specific standards for the type of system (clinical laboratory system, ADT system, resource scheduling system, etc.), then replacing such a system with an improved one could “potentially” be as simple as plugging another one in that uses the same protocols. Such a level of clinical system inoperability does not yet exist.

Component adaptability with the use of HL7 or other standards can also apply to the automated patient medical record system in its communication with the CPR repository, source document repository and patient registry. As long as automated patient medical record system follows strict standards with respect to its communication with the CPR repository, source document repository and patient registry, the automated patient medical record system itself can potentially be replaced by another equivalent system (although this might be traumatic for the healthcare organization).

The automated patient medical record system can itself be viewed as multiple separate systems. In particular, as mentioned in chapter 12, the user interface can be considered to be a separate system from other parts of the automated patient medical record system, such as from its data components and communication with other clinical systems and with the CPR and source document repositories and patient registry. The user interface can thus potentially be changed without effecting the underlying automated patient medical record system--as long as a new user interface provides the exact same data as before, a new user interface can easily replace the new. For example, one user interface could be based upon selection from lists while a replacement one might require more textual input. A user interface could be changed to support caregiver workflows in a different fashion without change to the underlying system. (Because user interfaces should be viewed as being “replaceable”, they should not be the primary reason for selecting one automated patient medical record system over another.)

13.14 Database Design

Databases are a way of structuring and storing data, including patient lists, encounters, documents, patient demographics and caregiver information. For example, information in the automated patient medical record system described in section 13.8 can be stored on the automated patient medical record system’s databases. Databases connected with mainframes, central databases, are usually on one platform (i.e., one computer), while distributed databases are usually on many.

Most databases today are relational databases, with a paradigm of tables, where there may be a patient table, a patient encounter table, etc. See figure 13.52. (There are other types of databases that are stored in formats other than table structures, but these are only common on older mainframe systems, so this section will address the table paradigm only.)

Each row in a table is an instance in the table; for example there be a row for each patient in the patient table, a row for each patient encounter in the patient encounter table and a row for each diagnosis during a particular patient encounter in a patient encounter diagnosis table. Each instance is composed of data elements; for example, a patient table instance may be composed of data elements of patient identifier, patient first name, patient last name, etc. A set of data elements in a row in combination are usually set up with this set of data elements uniquely distinguishing one instance from another; for example the patient identifier uniquely distinguishes one patient from another; this unique set of data elements is termed a primary key in the table. In distributed databases, these tables (or entities) could be stored on different platforms.

Primary keys allow a particular instance of a table (i.e., a particular row) to be retrieved based upon the key, and allow consecutive retrieval in an identified order. Relational databases also allow retrieval based upon any other set of data elements in a table, some of these combinations of data elements can be specifically identified via indexes, allowing the database system to structure a table for quicker retrieval based upon that index.

A language that allows an application programmer to create a table, add a row to a table, select a row for a table and/or select data elements from a table, is called Structured Query Language (SQL). Some standard type SQL statements are SELECT (to select data), UPDATE (to change data), INSERT (to add rows) and DELETE (to delete rows).

For example, a SELECT statement might be “SELECT First_Name, Last_Name FROM Patient WHERE Patient_Identifier = ‘118386390’;”, where First_Name and Last_Name are data elements (columns) within a Patient table and Patient_Identifier is another data element (column). The row with the Patient_Identifier ‘118386390’ would be selected and First_Name and Last_Name would be returned.

Based upon parameters, SELECT statements could return entire tables if the condition selects multiple rows. Actually, this is the approach that relational databases used to create “virtual tables” from one or more tables. These “virtual tables” are called views. A common reason for creating views is to hide from a user information the user is not allowed to view.

Different tables of the database may have relationships with each other. These relationships can be expressed by entity-relationship (ER) diagrams, for example, as shown in figure 13.8. Entities are tangible objects, such as organizations, caregivers, patients, charts, encounters, procedures, etc. In general, each entity corresponds to a table. For example, there might be a relationship between a “patient encounter” entity and a “encounter procedure” entity of “occurs during”. Thus the relationship addresses all encounter procedures occurring during the patient encounter. To express this relationship, the encounter procedure entity (or table) would likely contain the patient encounter primary key as a data element. When a primary key of a table instance is stored in an instance in another table, this key value is termed a foreign key; for example, the patient key that is stored in an patient encounter table instance and the patient encounter key that is stored in an encounter procedure instance are foreign keys (see figure 13.52 again).

Now with one table referencing another table, there are potential problems in keeping the two tables in synch. For example, if the encounter is deleted and the associated encounter procedures are not deleted, then the encounter procedures are referencing an encounter that no longer exists. Referential integrity is a rule that states that every foreign key value in one table must either match a primary key value in some other table, or it must be null.

Some database systems allow stored procedures, essentially processing code, to be stored along with the data in a database. Such stored procedures can be triggered based upon a set of rules. For example a stored procedure could be automatically executed when an “encounter” instance is deleted in order to delete all referenced instances in the “encounter procedure” table first.

Applications updating databases are usually written in terms of transactions where each transaction either commits database updates or backs them out, in either case leaving the database in a consistent state. This technique is called a two-phase commit.

The main purpose of a two-phase commit is to stop other applications that are running on other workstations from writing on the same part of data your application is writing to, and thus creating garbled or inconsistent data. A part of the two-phase commit process, but of more general use, is to allow an application to lock parts of a database (e.g., several tables) for a time period, disallowing other applications from updating those parts of the database until the application issues an unlock.

In order to ensure the stability of tables, a technique called normalization can be used. Normalization is a procedure for placing data elements in tables in databases according to a set of dependency rules so as to create stable data structures that minimize data redundancy and maximize data independence. Normalization includes doing the following:

· First Normal Form (Eliminate Repeating Elements): Elements in a table that repeat for each row should be moved to a separate table with one repeated item per row of the new table. For example, the encounter procedures should be a separate table and should not be made part of the patient encounter table, as the one table approach requires that the designer assign a maximum for the number of encounters, creating for a badly structured table.

· Second Normal Form (Eliminate Redundant Data): Data in a table that is not directly related to the primary key should be moved to another table. For example, a department name and department number in a physician table should not both be in the physician table; these should, instead, be stored non-redundantly in a department table.

· Third Normal Form (Eliminate Many to Many Relationships): Separate tables should be created to get rid of many to many relationships in E-R diagrams. This enables relationships to have more definite meanings.

There are 5 accepted normal forms, but the above 3 are the ones most commonly followed.

Although normalization removes some forms of data redundancy, sometimes data redundancy is necessary for efficiency reasons, especially in a distributed database system. For example, the clinical laboratory system directory of tests (a type of master file) might exist in the clinical laboratory system, and might be replicated in the automated patient medical record system so clinical laboratory systems orders could be made in the automated system. Such replicated parts of the database usually must necessarily consist of fairly static information; such information might, for example, only be updated nightly in batch, and thus potentially be somewhat out of date for a while.

Data integrity is another desirable characteristic of databases. Every table, row and data element within a table must be used precisely for what it was intended. For example, an appointment table must not be used to store a visit, as these are two different things. In order to insure later integrity of information, a data element to store the height of an object must not be used to store the width of the object, even though both may use the same units of measurements. To insure this data integrity, a data dictionary is often created to describe the structure and use of each table, each row, and each data element, and describe the relationship between tables identical to corresponding relationships in ER diagrams.

A data dictionary contains meta-data, data about data. For example, a data dictionary description of a prescription (medicine order) table might include the following meta-data for each row and data element (only selected information is shown):

patient = Unique Healthcare Identifier (key field)

date = date of prescription (key field, in form MMDDYYYY, where MM is numeric month, DD is day of month and YYYY is the year)

time = time of the prescription (key field, format: 999999 where 999999 is military time including hours, minutes and seconds with values from 000000 to 235959)

priority = urgency of prescription (values: “STAT”, “routine”, “rush”)

encounter date = date of encounter when prescription was made

encounter time = time of encounter when prescription was made

prescriber = Unique Physician Identifier Number identifying the clinician ordering the medication

drug name = brand or generic name of the drug and manufacturer

dosage = quantity, units

route = route of drug

schedule = times per day.

Database design in the system analysis step involves database analysts working with system analysts (who represent the automated systems which will use database), and domain experts and domain analysts (who understand the business--e.g., the healthcare business-- and thus understand the meaning of the data in the database); the database analyst serves as a facilitator to gather information to design the database. Database design consists of logical database design and physical database design. Logical database design identifies sets of data (called “tables”, “records” or “entities”) making up the database, the format of data elements making up each entity, and the relationships between the entities. A way of defining sets of data (called “entities”) and relationships between these entities are entity-relationship (ER) diagrams, as previously discussed in section 13.8. A standard way of defining the data elements making up each entity (or table) are data dictionaries. Physical database design uses the logical design information to map the data in the database to physical files. The actual database is created in the implementation step.

Database administration is an important organizational duty during the design and after the implementation of the database. Database administration are the tasks necessary to insure data integrity including referential integrity, non-redundancy of data, immediate up-to-dateness of data, integrity of the meaning of data as recorded in data dictionaries, security, and database software installation and upgrades.

A word about our example tables in figure 13.52: The tables are unrealistic in that unique alphanumeric identifiers would probably be kept for caregivers (e.g., NPI identifier), rather than names that may occur in many different forms; for example, when names are used, “Jonathon” might be stored one place for the first name, “John” in another place and an initial in another place. And these tables are also unrealistic in that a CPT or other definitive procedure code is likely to be stored for a procedure, rather than a vague textual procedure description.

This section presents the briefest of introductions to database systems. There are many comprehensive books on databases, such as [13].

13.15 Program Design

Programs are instructions coded in a computer language.

The previous parts of this chapter, in essence, dealt with establishing an infrastructure for the programs constituting the application. For example, the programs constituting the automated patient medical record system would use the databases defined in this chapter, would implement the interfaces defined in this chapter, would requires coding of the agents defined in this chapter, and would implement the staging and security techniques in this chapter.

Programs are created for the central system, local system servers and local system workstations. If there are patient registries, CPR repositories and source document repositories, there is additional code and programs for these.

The central system must keep a complete clinical summary for all patients in the HMO and pass the clinical summary down to a local system when there will be an encounter to occur at a facility associated with the local system. The central system is responsible for handling communication with the outside world, including patient registries, CPR repositories, source document repositories. It is responsible for communication with ordering systems, sending results and alerts to the local system of the order.

The local system must handle the user interface described in Chapter 12, alerts to a caregiver, and downloading of clinical summary information and document locations after an encounter; it handles communication with local clinical systems. For the user interface in Chapter 12, there are functions for each of the icons shown in figure 12.6 and described in section 12.2.2 (functions for patient lists, patient identification, clinical summaries, patient chart, searching, cases, encounter synopses, ordering, documentation, appointment making, e-mail and messaging, medical references, recording the position, making a note, providing help to the user) and an overall function for the main program that displays the icons and controls menus and over parts of the main screen, in essence, tying all the other functions together.

There are a number of different software design strategies available for defining the necessary programs in each system. There are quite a few books on software design, including [14,15,16]. Two major categories of software design are structured design and object-oriented design.

13.15.1 Structured Design

Structured design is a way of designing an application system by breaking the sys8tem program code into subsystems, by breaking subsystems into functions, by identifying programs making up the functions, and identifying routines used by the total of programs and subprograms. A subsystem is a set of functions that are logically grouped together, with the subsystems, together, making up the system. A function is the smallest discrete, complete set of code of an automated system that can be initiated by the user and run to completion to produce a single purpose set of results (e.g., a stand-alone function to look up patient demographical information about a patient, a function to issue an order for medication, or a function to make an appointment for a patient). Programs are logical combinations of code specific to the subsystem functionality. Routines are general purpose code that may be used in many different programs, generally including the passing of data via input and output parameters associated with a routine name.

For example, for the automated patient medical system, there might be subsystems that include a Patient Lists, a Patient Identification, Patient Chart, Searching, Ordering and Documentation subsystem, among others. For the Patient Identification subsystem, there might be two functions, one to search for the patient’s identifier based upon patient characteristics (e.g., last name and birth date), and another to display patient demographics information, such as full name, sex, birth date, phone numbers, address, based upon the patient identifier. For each function, there might be one or more programs providing the code for each function. Routines to support the Patient Identification subsystem and its functions might include various routines, for example, one to get the patient identifier based upon the characteristics, one to retrieve patient demographics and patient benefits based upon the patient identifier, and one to do a Soundex search for a patient identifier for patients whose names sound like an entered name. For example, a routine with parameters, “Get-Patient-Name (Patient-Identifier, Patient-Name) ” with input parameter of “Patient-Identifier”, and output parameter “Patient-Name” might return the patient’s name given the patient’s identifier. In the past, such routines were put together into “subroutine libraries”, groups of related routines.

Real-time systems are often built using on-line transaction processing (OLTP) systems. A module within an OLTP system is called a transaction. Structured design also applies to OLTP systems. In real-time systems, there are many users competing for the same databases. A transaction is code that makes logical updates to databases, taking the databases from one consistent state to another; in other words, if the transaction for some reason fails to complete, then the databases are backed out to the previous state.

A structure chart might be set up to identify the system, show the breakup of the system into subsystems, show the breakup of subsystems into programs, and identify routines. See figure 13.53 for a structure chart for the automated patient medical record system. For each program and routine, program design language (PDL) to describe in structured English what the program or routine does could be later used to create the program or routine in a programming language.

Defining the high level modules first is called top-down design; modules not yet defined in terms of code or PDL can be replaced with a place holder that performs nothing or much less than the full function of the module, called a “stub”. Bottom-up design is defining low-level modules first and then combining them together into higher level modules.

13.15.2 Object-Oriented Design

Object-oriented design is a way of designing an application system by breaking the system program code into objects. Objects are abstract or real-world entities. Examples of objects in the automated patient medical record system are patient, chart, order, appointment, and e-mail. Examples of objects appearing in windows are windows, bitmaps, drop-down menus; message and dialog boxes, group boxes, static text boxes, scroll bars, input fields, single-selection lists, radio buttons, check boxes, and tabbed structures.

An object class can be created for an object, that

· defines data associated with the object

· defines routines called methods associated with the objects

· defines what data is available to programmers using the object class (usually all data is hidden)

· defines what methods are available to programmers using the object class and which are not.

For example, figure 13.54 shows an object class for a mail message. The data is shown at the top of the object class, being marked “private” meaning that the data is not available for retrieval or setting by programmers using the class. Methods available to outside programmer use are “Mail Message”, “Send Message”, “Forward Message” and “Delete Message”. The “Format Message” method is “private” and not available to outside programmers. Hiding data and methods within the object class from outside programmers is called encapsulation, which is an example of the more general concept of information hiding.

A programmer using the object class can create an instance of the “Mail Message” class, causing the “Mail Message” routine to be executed, probably setting up a new mail message with the programmer passing the text, sender, receiver and other information. Use of the “Send Message” for the instance could send the message off to the receiver.

The automated patient medical record system programs can be defined through use of objects; however, a more common use of object-oriented design is to create object libraries that can be used in place of subroutine libraries. For example in the last section it was mentioned that a set of routines all connected with handling patient information could be combined into a “subroutine library”. These routines can be more elegantly combined into a “patient” object, together with other objects in an object library.

An important concept for objects and object classes is inheritance. One object class can be inherited from another. For example, figure 13.55 shows the object “inpatient” and “outpatient” being inherited from the object class “patient”. When an instance of “outpatient” is created or an instance of “inpatient” is created, then an instance of “patient” will be automatically created. Any public method within the object class “patient” will be available through the object class “outpatient” or “inpatient”; thus, any method which applies to both outpatients and inpatients can be defined once for “patient”.

The object class from which other object classes inherit characteristics (e.g., patient) could be identified as an object class which the outside programmer cannot use to create an instance. Such a class is referred to as an abstract data type. An abstract data type allows the same data and methods to be used by all inherited objects.

13.15.3 Aspect-Oriented Programming

Object-oriented design requires that methods be associated with objects. This gets in the way of defining general-purpose “methods” that cross the boundaries of many objects, applications or computer systems.

A new programming paradigm is aspect-oriented programming [17]. In aspect-oriented programming parlance, “methods” are referred to as “units” and units providing this crosscutting modularity are called aspects.

Aspects are useful in providing some capabilities of use by agents, which, as we pointed out in a previous section, can cross applications or computer systems [17,18]:

· logging

· error and failure recovery

· distribution of information among computers

· security strategies

· resource sharing

· synchronization policies.

13.14.4 Use of Structured Design, Object-Oriented Design, and Aspect-Oriented Programming in Combination

Structured design, breaking the system into subsystems and modules, can be used in combination with creation of object libraries, which can substitute for subroutine libraries. Aspects can cross subsystems.

References

[1] Duke web site, http://www.mcis.duke.edu contains information on many healthcare standards including HL7.

[2] Martin Fowler, Kendall Scott, UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley, 1997.

[3] Stephen R. Gardner, “Building the Data Warehouse”, Communications of the ACM, September 1998, Vol. 41, No. 9, pp. 52-60.

[4] Thomas J. Mowbray, Ron Zhavi, Essential Corba: Systems Integration Using Distributed Objects, John Wiley & Sons, Inc., 1995.

[5] Dr. Richard Grimes, Professional DCOM Programming, Wrox Press Ltd., 1997.

[6] Stephen A. Finkler, Robert F. Wagner, Essentials of Cost Accounting for Healthcare Organizations, Aspen Publishers, Inc., 1994.

[7] Simson Garfinkel, Web Security & Commerce, O’Reilley & Associates, 1997.

[8] HIPAA regulations are at website, http://aspe.os.dhhs.gov/admnsimp/.

[9] For information on electronic signatures, see http://www.hipaadvisory.com/regs/securityandelectronicsign/electronicsignature.htm.

[10] Benjamin Wright, ‘The Law of Electronic Commerce: EDI, E-mail, Internet, Second Edition’, September 1995, Little, Brown and Co.

[11] MQSeries Concepts and Architecture, Second Edition (December 1994), IBM Corp., Order Number GC33-11 42-00, 1994.

[12] Tommy Thorn, “Programming Languages for Mobile Code”, ACM Computing Surveys, September 1997, Vol. 29, No. 3.

[13] James Martin and Joe Leben, CLIENT/SERVER DATABASES: Enterprise Computing, Prentice Hall PTR, 1995.

[14] Ian Sommerville, Software Engineering, Addison-Wesley Publishers, Ltd., 1996.

[15] Kenneth E. Kendall, Julie E. Kendall, Systems Analysis and Design, Third Edition, Prentice Hall, 1995.

[16] Steve McConnell, Code Complete, Microsoft Press, 1993.

[17] Sandra Kay Miller, “Aspect-Oriented Programming Takes Aim at Software Complexity”, Computer, April, 2001, Vol. 34, No. 4, pp. 18-21.

[18] Xerox Parc has a website on aspect-oriented programming, http://www.parc.xerox.com/csl/projects/aop/.

NEXT
TABLE OF CONTENTS

Copyright © 2000-2001 Michael R. McGuire

Duplication not permitted without express written permission

Comments? mailto:Michael.McGuire@abac.com