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