Implementing OCIS at the Ohio State University

Elizabeth E. McColligan1

Editors’ Introduction OCIS has been distributed to two other cancer centers for implementation. In 1984, the New South Wales State Cancer Council began to implement the system in Australia. They first sent some clinical staff members to observe the JHOC operations, and later a computer specialist (Parvis Ostovari) spent three months at JHOC. He had to learn MUMPS, TEDIUM, OCIS and clinical computing. At the end of that time, he took the various systems—about 6000 programs in all — back to Australia.

The system has been operational in the Prince of Wales Hospital, Sydney, for about four years. Its database contains information on some 2000 patients. It is called the Oncology Research Central Information System (ORCIS) in Australia, and it is described in a journal article.2

The second OCIS transfer is presented in this chapter. In this case the responsible person participated in the development of OCIS subsystems and was experienced in both of the development languages used: MUMPS and TEDIUM. The discussion covers the first year of conversion activity at Ohio State University.

Background The Arthur G. James Cancer Hospital and Research Institute of The Ohio State University (OSU-CHRI) is a 12-story, free-standing building immediately adjacent to The Ohio State University Hospitals.

‘Elizabeth E. McColligan, M.S., is Director of the Computer Center at the Arthur G. James Cancer Hospital and Research Institute of The Ohio State University, Columbus, Ohio.

2Terry J. Hannan and Michael Vincenz, Introduction of a Computer-Based Oncology Patient-Care System in a Teaching Hospital, Medical Journal of Australia, 148: 242-247, 1988. There also is a short paper in Cancer Forum, November 1987.

Construction of the OSU-CHRI began in July 1984, and it is scheduled to open in the first quarter of 1989. The 260,000 square feet of space includes an up-to-date Radiation Therapy Center on the ground floor. The Outpatient Department, located on the first and second floors, will be able to accommodate 100,000 outpatient visits annually. A sophisticated Bone Marrow Transplant Unit, consisting of 24 inpatient beds and modern treatment and research areas, will be located on the third floor. An ultramodern operating room suite, consisting of 6 operating rooms and equipped with intraoperative radiation therapy equipment, will be located on the fourth floor. The seventh, eighth, ninth, and tenth floors will house a total of 136 inpatient beds to facilitate the treatment of the 4800 inpatients expected to be admitted by the OSU-CHRI annually. The eleventh and twelfth floors provide approximately 26,000 square feet of basic research space.

The OSU-CHRI will support an interdisciplinary approach to the treatment of cancer and facilitate state-of-the-ait cancer research. It is expected that most patients treated at the Institute will be on some type of research treatment protocol. The Ohio State University is currently recognized as a Comprehensive Cancer Center by the National Cancer Institutes and is a major contributor to the Southwest Oncology Group (SWOG). The Ohio State University also participates in other clinical cancer research protocols, including the National Surgical Adjuvant Breast and Colon Programs (NSABP), the Head and Neck Oncology Intergroup, the Gynecological Oncology Group, the Melanoma and Limb Perfusion Study Group, the Brain Tumor Study Group, and the Urological Tumor Study Group.

The Need for a System The Bone Marrow Transplant Program (BMT) at The Ohio State University was begun in the summer of 1983 when Dr. Peter J. Tutschka joined the faculty. Dr. Tutschka had been at Johns Hopkins University prior to joining the faculty at The Ohio State University and was familiar with the OCIS system. Dr. Tutschka brought OCIS to the attention of the hospital’s administration and Dr. Arthur G. James who had been lobbying for a Cancer Hospital and Research Institute for many years.

Dr. Tutschka appreciated the necessity of a clinical information system to assist with the data management needs of the BMT program. Although none was immediately available to him, there was a version of the Sloan-Kettering research data management system in use at OSU as part of the Comprehensive Cancer Center (OSU-CCC) program (see Serber). Although this system was unable to address many of the clinical information needs of the BMT program, it was decided to use this system for some of the emergent data management tasks. This is a MUS-based system. It allows the user to define groups of data, up to 100 items per group, and provides for “repeated” items, such as laboratory tests, and nonrepeated “core” items.

The OSU-CCC system can store only one value per day for each of the repeated items, which is a limitation with respect to clinical management. Another limitation is that the data are stored by protocol. To get around this, a general “data”

protocol was defined for all BMT patients. The system provides for the generation of basic flow sheets and allows searches of the database and the definition of aggregates, thereby facilitating the generation of statistics by diagnosis, protocol, and other user-defined cohorts. Finally, the system enables the definition of cohort files that can be transferred to more sophisticated statistical packages. All data must be manually entered and, as mentioned previously, only one value per day can be stored.

The first bone marrow transplant was performed in February 1984, and the BMT program began using the OSU-CCC system in a production mode by February 1986. Initially, data were entered on current patients, and eventually the backlog of data on patients who had been transplanted prior to 1986 was entered. In January 1988, when the conversion of the data from this system to OCIS occurred, the system had data stored on 125 patients.

Selecting a System In early 1986, before the decision to go ahead and implement OCIS was made, a review of several other systems was carried out. These systems ranged from general medical-record-type systems, in particular, COSTAR (COmputer STored Ambulatory Record; see Barnett), PROMIS (PRoblem Oriented Medical Information System; see PROMIS Laboratory), and TMR (The Medical Record; see Stead), to systems developed specifically for Cancer Centers, in particular, WISAR (Wisconsin Storage And Retrieval Data Management System; see Friedman), CDMS (Cancer Data Management System; see Horwitz), and CPIS (Clinical Protocol Information System; see Wirtschafter).

The general medical-record-type systems were considered too general because they did not provide any tools that would specifically aid in the clinical management of oncology patients, particularly with respect to protocol management. Of the oncology-specific systems reviewed, CDMS and CPIS were the most clinically oriented; however, both were much more limited in scope than OCIS. Although the primary focus of both CDMS and CPIS was the management of clinical protocols, OCIS was much more general in its orientation to managing clinical data for all patients, as well as having protocol management capabilities. It was decided that OCIS represented the most advanced system specifically developed for oncology patient management available at the time. We concluded that OCIS could provide most of the baseline functionality we required and would provide a solid foundation that would facilitate the development of an OSU-specific oncology clinical information system. Consequently, OSU-CHRI elected to install OCIS as a prototype on the BMT unit.

Installation History The saying “ignorance is bliss” can certainly be applied to our notions of what would be involved in bringing the OCIS system up at the OSU-CHRI. As will be seen, the basic assumption that the system as it was written and functioning at the Johns Hopkins Oncology Center (JHOC) could be easily ported to OSU-CHRI was not completely accurate. There were two basic causes for complexity in the system transfer.

When we decided to implement OCIS at the OSU-CHRI, we recognized that OCIS was not a turnkey system. We expected that there would be several modifications to be made and that many of the system dictionaries would have to be defined. However, we did not fully anticipate the magnitude or the level of complexity of the modifications we would be undertaking.

Our second underestimation is linked to the ever-present optimism of developers. It is known that the installation of a hospital information system can take 6 to 24 months, even when there are no programming changes. In our case, the author, working half-time on the conversion project, and one full-time programmer with MIIS experience expected to bring up and customize a 5000-program system with 1400 relations that ran on networked computers supporting 100-plus terminals. And we promised to have an operational product that supported a dozen terminals on aMicroVAX within a year. We did succeed, but as the last sentence suggests, it was a more difficult project than we had expected initially.

Standard Conversion Requirements Every health care facility has local conventions and site-specific requirements. Vendors of clinical systems design their products so that they can easily accommodate these local demands. In the case of OCIS, the system was developed for internal use, and the transporters had to assume the responsibility for making the necessary changes. Because I had worked on a part of the OCIS and was familiar with the TEDIUM1 development environment that was used, I was confident that many of these so-called routine changes would not be difficult to make. This section describes the expected modifications and our experience with them.

Patient Identifier. The patient identifier, or medical record number, is a sevendigit number at Johns Hopkins Hospital. At OSU it is a nine-digit number. Although this was a fairly straightforward modification, it was quite extensive. TEDIUM maintains a data dictionary that is used by all generated programs. To change the format of the history number (HNO) field primarily involved changing the element definition, which then was automatically reflected in the table definitions. However, the extensiveness was reflected in the fact that the element HNO is used as an index item in some 552 tables and as a data element in 53 tables. Therefore, I would estimate that more than half of the programs referenced these tables, and many made direct reference to the element HNO, either to its format or to check its range.

The range of the HNO at JHOC was used to categorize patients. Three ranges were used. Hospital HNOs were less than 8000000, numbers between 8000000

'TEDIUM is a trademark of Tedium Enterprises, Inc.

and 8999999 were used for outreach patients treated outside Hopkins, and numbers greater than 9000000 were “temporary” numbers used for preadmissions, etc. Medical record numbers at OSU are usually nine-digit numbers starting with 900 assigned by the Medical Records Department. However, medical record numbers may also be social security numbers or some other number assigned by Medical Records but not starting with 900. We chose to designate “temporary” numbers as those beginning with 999. As OSU does not have an outreach program at present, we did not need this category of medical record numbers.

This conversion modification was straightforward, but quite extensive. Fortunately, most of the HNO processing was performed by two input routines. However, some of the programs that had to make decisions based on the logical content of the HNO did so by using procedural code. As a result, it was decided that we would modify the registration and the two central patient identification routines initially, and we would review the need to alter other routines as we brought up each function. The initial modification required only several days. The remaining routines are still being modified, as the conversion is not complete and not all functions are active.

Clinical Laboratory Link. It was imperative that we establish a communication link that would permit the electronic transfer of laboratory data. This required writing routines on the laboratory system that would query the CHRI computer to determine which patients’ data should be transferred and then search the laboratory system and transfer the resulting file to the CHRI system. Once the data are received, CHRI system reads the VMS file into a MUMPS global and then processes the data. Because the laboratory does not use unique laboratory codes (the laboratory code and specimen type are both required to uniquely identify a result), we needed to create and define a translation dictionary. This laboratory translation dictionary maps the laboratory code and specimen type into a unique Item Dictionary code. (The OCIS Item Dictionary provides mnemonic names, short names, formats, and the ranges for all test values, findings, drugs, etc., that are used in the clinical outputs, for example, in the plots and flows. Naturally, this dictionary is site specific.)

The laboratory transfer routines had to include procedures to hold the data in case the CHRI system was down and also to ensure that the data runs would be contiguous in case the laboratory system was down. This data transfer is done over an Ethernet link in a batch mode three times a day, 9:00 a.m. , 3:00 p.m. , and 11:00 p.m. Because of the load on the laboratory system and its inability to handle much of an additional processing load, this link presently only involves hematology, chemistry, and immunology data. University Hospitals’ administration is presently considering upgrading the laboratory computer system, and it is our hope that we will be able to receive bacteriological (microbiology), blood banking, and surgical pathology data in the future. University Hospitals is also in the process of installing a fiberoptic network, which we hope will facilitate the realtime transfer of these laboratory data.

As one would expect, we also needed to write programs that would recognize errors, such as no item code defined, name mismatch, and comment field too long. The OCIS programs then were modified to allow data coordinators to review and correct the errors and reprocess the corrected data.

Dictionaries. As the reader may be aware, the OCIS implementation draws heavily upon dictionaries. Excluding the dictionaries used by the daily care plan functions, the pharmacy system, and the blood product management programs, there are over 100 standard dictionaries. Some, like the Item Dictionary, play a central role in most clinical processing ; others, like the dictionaries of valid units and zip code-state combinations, are used only for input validation.

We are still in the process of redefining many of these dictionaries and continually updating others. Several crucial dictionaries had to be defined very early in the project. These included the Item Dictionary and dictionaries for flow-sheet and plot definitions, providers, diagnoses, reasons for admission, and protocols. The most extensive and time-consuming dictionary was the Item Dictionary and a related laboratory translation dictionary. As of the end of February 1988, our Item Dictionary contained approximately 1000 item codes. (650 laboratory codes, 50 clinical status items, and 300 medications.)

Help Message Updates. Another task that had to be undertaken was modifying the help documentation. TEDIUM manages the help messages as an extension to the data dictionary and program specifications; changing the data model definitions also changes the help messages that the end user sees. For us, customizing the help messages involved editing element descriptions, menu help messages, and internal program help messages. The main driver menus and generic variables (such as HNO) were updated initially, whereas the internal program help messages were modified as we implemented a particular function.

Menu and Report Headings. It goes without saying we had to replace all of “the Johns Hopkins Oncology Center” headings with “The Ohio State University”. Although this was not a difficult task, it was time consuming and tedious. TEDIUM did help us somewhat with this modification in that many of the headings were stored in frames that are shared by many programs; a change to the frame is reflected in the output of all the associated programs. Unfortunately, some programs also used procedural code to augment the headings.

We decided to make modifications to only the frame programs initially and then to modify the individual routines, mainly report routines, as we brought up the various functions.

Data Conversion. The first phase of OCIS implementation was to use the system in a prototype mode on the Bone Marrow Transplant Unit. As mentioned earlier, data dating back to 1984 had been collected via a research data management system on 125 BMT patients. As a result, it was necessary to write routines that would allow us to transfer that database to the CHRI system and then load as much of the data as possible into the OCIS prototype database. This required yet another translation dictionary because items were stored by number on the research database. Although all of the repeated clinical data items, such as temperature and hematocrit, were added to the Item Dictionary, there were several core items that did not exist in the OCIS database. These items included the BMT unique patient number, a sequential number assigned when the patient is accepted for transplant; donor name and medical record number; and other BMT-specific data. As a result, we created a BMT-specific table consisting of 10 items. We also wrote routines to add and edit this table and modified other display routines so that if the patient is a BMT patient these data are displayed along with other general patient information.

Customizing OCIS for OSU-CHRI In transporting OCIS to OSU-CHRI it was necessary to adapt the system’s operation so that it would be “natural” to the CHRI users. Recall that OCIS was developed for JHOC as an internal product over a period of many years. Its users had grown with the system; many of the clinicians helped to define how that system would perform. Because OCIS was relied upon very heavily at JHOC, and because there was a large and stable body of users at JHOC, new OCIS users found it easy to accept OCIS “warts and all.” Naturally, one could not expect this same willingness when introducing a new system to a new set of users.

Although OCIS is an on-line system, user interaction at JHOC, particularly with regard to the health professional user, was designed to manage the bulk of the clinical processing in a paper-oriented fashion. As a result, the system tends to have a batch mode approach to many functions. While the number of health professionals interested in an on-line clinical information system at OSU may not be so numerous as those at JHOC (especially since we are still in the prototype phase), those who are interested want to interact with the system directly and not via hard-copy reports or with the aid of a data coordinator. Although we recognize the need for data coordinators, we have taken the approach that the system should also support more direct physician and health care professional interaction. Part of this is due to the fact that the prototype users have had experience with a research data management system that gave them on-line access to data, permitted on-line report generation and listing, and was not strictly geared to hard-copy output.

Dictionaries. Physicians and other health care providers at OSU do not use a unique provider ID. (The Johns Hopkins Hospital has a central office that assigns unique IDs used throughout the institution for all clinical and administrative functions.) As a result, we modified the dictionary entry program so that these IDs are generated by the system and are only used for internal reference. The users of the system interact with the system via the provider’s name.

Another difference in dictionaries involved the Protocol Dictionary. Health professionals at OSU were not accustomed to referring to protocols by their IDs,

but rather by their short names. Although both the internal and SWOG protocols did have IDs, they were not generally used. In addition, the format of the protocol IDs differed, and so we had to modify the element definition and correct the programs that referenced the protocol ID. It was also necessary to modify several routines that displayed only the protocol ID so that they would display the short name in place of or in addition to the ID. This was a case of modifying the system to reflect what the health professionals were used to, a problem we encountered frequently and that has been responsible for most of the unexpected modifications.

Although the unit or location variable is stored in a dictionary, it was often referenced by the specific values used at Hopkins. For example, often a prompt was used that specified the various units at Hopkins. This was most often the case when selecting reports. This had to be changed so that the prompt did not specify the various units but only asked for a unit and then checked to be sure a valid unit had been specified by checking the dictionary.

Another minor modification that was used for several dictionaries was the use of an index option when prompting for a code. For instance, the format sequences used by the data entry and data coordinator staff were not always as mnemonic as one would like, and we found that often one had to go through several characters in the alphabet before the correct code could be identified. Our users therefore asked for an index option that could be used in addition to the character prompt to list through all of the possible codes quickly and in a more “user friendly” fashion. We also implemented this option in the Reason for Admission Dictionary, as well.

Preformatted Plot and Flow Updating. The general method that OCIS uses to update the preformatted flow sheets and plots is a batch mode approach. At various times, usually at night and after laboratory link runs, the unformatted clinical data are updated into the preformatted plot and flow files. There are three basic formats used by the OCIS clinical displays. One format contains the clinical data. This can be displayed in the Data format or the vertical flow-sheet format; these displays always contain the most current data. Because the plots and horizontal flow sheets present the data in a different sort order, the rapid production of output is managed best when the data are copied over into a format “close to” the display being produced, that is, the preformatted data. In JHOC, these displays are printed and seldom called on line; therefore, it is most efficient to update them infrequently or on demand. The on-demand update results in a response delay; displaying the preformatted data is immediate.

This design was not acceptable for OSU. We felt that the primary purpose of the system was to provide clinical data to the health care professionals in a meaningful way. If we were to have an acceptable system, we needed to be sure that the data being accessed by the health care providers were in the most convenient and useful format, flows and plots, and that the data were as up-to-date as possible. Therefore, we decided to rework the update processing. As we now process the clinical data, we record the date of the data in a new global called REGEN. After all data have been updated in the basic OCIS clinical data table, we submit a background job that regenerates the preformatted flow and plot files from the earliest date in REGEN to the current date. In effect, we do the daily JHOC processing after each data update process.

Although this may not be entirely efficient from a computational point of view, it guarantees that the preformatted data are as current as possible. The overhead is not great at this point in time, but we are aware that this may have a negative effect on system performance under heavy loads. We plan to review the regeneration step so that only days that have actually been updated are regenerated.

Redesign of Flow-Sheet Format. Although OCIS has the ability to store multiple data values per day, only the first value of the day is shown on the standard horizontal flow sheet in both the on-line and hard-copy forms. We had the need to show all data values. In addition, the Medical Records Department required that the time associated with each data value and the normal ranges for the values be printed on the hard-copy flows. Because of character space limitations, we decided not to display the times or the normal ranges on the on-line flow, but the values are sorted by time, and we provide an option to look up normal ranges. Although we have the need to record normal ranges by age and sex eventually, we have decided to use the single-range scheme supported by OCIS at present. This is acceptable because we have opted to use the abnormal flag that is determined by the laboratory and sent with the result. The range stored as part of the Item Dictionary is used only as a reference and not to determine the abnormality of a data value. In the future we do plan to implement a more sophisticated abnormal range scheme based on age and sex.

Data Value Comments. Although OCIS has the ability to store comments with each data item, this feature was never used at JHOC and therefore was not fully implemented in OCIS. Our users felt that the comment field was essential, particularly in light of the fact that the laboratory routinely sends comments as part of the result. This required modifying many of the data entry routines and all of the clinical data display routines, both the unformatted data displays (Figure 1) and the flow sheets. It also required that a check be added to the plot routines: If the data value is not numerical, then look for another data value for that day until either a numerical value is found or there are no more data values for the day.

Other format changes were also made to the flow-sheet routines to satisfy both the additional requirements, as well as requests from the prototype users. There are two options available when requesting a hard copy of a horizontal flow: a flow with times and normal ranges, which makes use of a 132-column compressed print mode (Figure 2), and one with no times or ranges, which uses the standard 80-column print mode (Figure 3).

Refinement of Plots. With respect to the plot function, we found hooks for features that had been planned for in OCIS but had not been implemented. For instance, the plot definition routines allow for definition of an unlimited number of

Figure 1. Sample unformatted data display.

items. However, the actual plotting routine only used the first two items. Because we chose to keep our hematology results, which come from the Main Laboratory, separate from the special Hematology Laboratory results, we needed to be able to plot a WBC from both the Main Laboratory and the special Hematology Laboratory as one item (There are separate WBC definitions in the Item Dictionary.) We also had the desire to plot more than two items on one graph. We have modified the plotting routines so that as many items as are defined will be plotted, but we have also put a limit on the plot definition of 10 items. Of course, we cannot have more than two scales, so the items must be correlated to a certain extent, and a plot could become difficult to interpret if too many items are selected; but we have left this to the user’s discretion.

Data Entry Routines. OSU does not have an automated medication administration system, so we must manually enter the medications administered in the inpatient area and those prescribed in the outpatient area. The two most efficient ways to enter these data are as either a batched group or a formatted sequence. Because we had modified the way in which the formatted data were updated, this also

Figure 2. First page of a sample compressed print flowsheet with times and normal ranges.

meant we had to modify the data entry routines to reflect the update changes. In addition, since we allow comments to be entered along with a data value for every data item, we needed a way of entering comments efficiently. Because comments are only occasionally entered, it was not efficient to prompt for a data value and a comment for each item. Therefore, we adopted the convention that a semicolon (;) would separate the data value from the comment field.

As mentioned previously, our prototype unit had been using another research data management system and had certain expectations. One of the features of the OSU

Figure 3. Last page of a standard 80 column flowsheet showing list of abbreviations.

-CCC system was easy data entry. Data entry on that system was similar to the formatted sequence data entry option in OCIS. However, one key feature that OCIS did not have was the ability to jump to various items in the sequence, including forward, backward, and to the end of the sequence. The lack of this feature in OCIS was a source of dissatisfaction to our prototype users. The slash mark (/) allows the user to get to the end of the list; a slash mark and a six-character Item Dictionary code allows the user to jump to that item in the sequence (Figure 4). The data entry time savings and the sense of satisfaction experienced by our prototype users was well worth the one day it took to rework these data entry routines.

BUN - BLOOD UREA NITROGEN : :

GLUC - GLUCOSE : !

URIC - URIC ACID : :

CREAT - CREATININE : : /GLUC GLUC - GLUCOSE : ! 70

URIC - URIC ACID i :

CREAT - CREATININE : :

NA - SODIUM : : 140

K - POTASSIUM : ! /

(A)CCEPT (R)ETRY (I)GNORE Figure 4. Sample data entry sequence showing use of 7" character.

Menu Reorganization. We have modified several of the main menus to accommodate the differences in the way the system will be used at OSU. Both the data coordinators’ and the health care professionals’ perspectives have been considered. We have changed menus to allow access by health care providers to some functions that were previously restricted to data coordinators. We allow health care professionals to define flows and plots and to enter certain data, such as protocol starts and events. Because we are just trying this feature out, we do not want to allow all health care professionals access to these functions at this time; we have restricted access to the BMT research nurse. To accomplish this, we simply added another level to the authority system. This new level allows greater access than the display of clinical data, but it is not so unrestricted as the data coordinators’ level. The authority system feature in OCIS allowed us to do this quite easily without having to change all menus. We did create a new menu that consolidates these additional functions. We have also made minor changes to several other menus in an attempt to consolidate similar functions and facilitate easy access to other functions. Most of these changes reflect the difference in how the BMT data coordinator has utilized the system at OSU.

Report Format Customization. Although it was anticipated that the institution name would have to be changed on all reports, this was expected to be a rather minor modification, restricted to the frame specifications and the report driver routines that set up report headers. Again, we chose to make this modification function by function in the same way we are making the medical record number and help message changes. However, it turns out that a bit more customization was required in “sprucing up” the report formats. Many reports were found to be difficult to read in that much of the data ran together. Clearly, this was a matter of preference and did not alter the function of the system in a major way (Figure 5). We feel, however, that by addressing human factors issues such as this, as well as the data entry customization mentioned previously, we have probably enhanced the users’ acceptance of the system and as a result improved its ability to convey information.

Figure 5. Sample of revised horizontal flowsheet format.

Planned Customization Activities The effort described in the previous subsections is limited to the development of a prototype implementation that operates on a small computer for a single unit. It does not implement—nor would it be useful to implement—all OCIS functions. Plans for the future are to complete the conversion of OCIS functions that are of value in this Phase I prototype and plan for the implementation of a larger Phase II system. I close this section with a brief discussion of some of the planned changes to the prototype system.

Protocol-Directed Care (Daily Care Plans). We have not yet implemented the daily care plan function of OCIS at OSU at this time. However, we have given this function much thought. From this author’s perspective, we find this to be the most interesting and exciting component of the system. We plan to make this component an area of emphasis for our system and hope to be able to develop some research projects along these lines. Specifically, we will initially be making modifications to this component so that it runs off the same Item Dictionary as the actual clinical database. At OSU the laboratory reports as part of each result both the battery code and the individual component test code. As a result, we will be able to verify the appropriate source of the result, the battery (CBC) or the individual result (WBC), or both. Because we also receive notification of pending results, we will be able to verify the laboratory tests that have been performed automatically without having to have the data coordinator manually verify laboratory procedures.

The other major modification we anticipate prior to initial use of the daily care plan is a more flexible order schedule. That is, we have a need to be able to order things more frequently than once a day, for example, vital signs or medications. Although we could accommodate this modification by simply printing the frequency of the procedure on the hard-copy care plan, we intend to develop a care plan that will function as a work list. We also would like to increase on-line use of this function in an attempt to get away from a hard-copy-based format and to promote more direct use of the daily care plan function by physicians and health care professionals. Our long-term research projects center around two main themes: (1) cognitive engineering issues, such as identifying what data are useful to the clinical decision-making process, and (2) human factors issues, concerned with how the data should be presented and what the system interface should look like.

Clinical Care Abstract. The other area of emphasis that we have targeted for further development is the tumor registry abstract. We plan to make the abstract more of a working clinical document, not only with respect to patient care but also from the clinical research perspective. We are developing a core of items that will serve as the basis for the clinical care abstract. We expect that many of these items are already part of the tumor registry abstract, but this core will be supplemented by a set of disease items and in some cases protocol and/or symptom-specific sets of items. We have not progressed far enough with this project to discuss the specifics, nor have we clearly defined the level of specificity we will use with respect to disease categorization.

Our goal is to attempt to develop an on-line clinical management record. This is different from an on-line medical record in that we are not attempting to capture all of the information contained in the legal paper medical record. Instead, we expect to organize and display on line the clinically relevant pieces of information contained in the paper medical record. Clearly, this is a controversial topic and will require a great deal of research and effort in identifying what are clinically relevant pieces of information. However, we are quite interested in how the clinician organizes and selects data, which is then used as a source of information in the clinical decision-making process. Our goal is not to replace either the decision maker or the paper medical record. We hope to develop a system that facilitates data collection and assimilation in order to provide information that can be used by the clinician in the decision-making process. We believe that part of this goal is not only to provide access to currently relevant individual patient information but also to develop and maintain a database that can also serve as a clinical research database.

Concluding Remarks Earlier I mentioned that the conversion of OCIS to meet the needs of OSU-CHRI was more difficult than we had expected. Nevertheless, with very limited resources, we have achieved success. That we did so is a tribute to the installation team, the clinicians and administrators who supported us, and the power and flexibility of OCIS. I close this chapter with some observations that may be of value to others tasked with the installation of a clinical system, even if it is not OCIS.

TEDIUM’S Influence OCIS was implemented using a development environment that offered a higher view of the system implementation. Like OCIS, TEDIUM was an internally developed product, and it was very helpful for me to have been experienced in its use before the conversion effort began. Although we have encountered a few minor bugs in TEDIUM, definitely fewer than a dozen, there was only one bug that caused us any difficulty. This was more a matter of inconvenience than a real problem. Without going into any detail, the design of the system assumed that a certain class of program would not generate more than 10 MUMPS programs. For very large “entry” programs this became a problem, but we were able to find a simple workaround.

It should be obvious from the above discussion that without TEDIUM we would not have been able to implement the OCIS system at OSU. OCIS is not a turnkey system, and it requires a fair amount of customization to the environment. Clearly, we have chosen to make more modifications than those that were essential, but we still feel strongly that because of the magnitude of the changes, it would have required many more programmer years of effort to implement them if TEDIUM were not available.

Administrative Commitment Adequate administrative commitment is essential to the success of a project such as this. The commitment must be of several varieties. The administration must recognize not only the need for an adequate level of resource support but also the OCIS dependence on other automated systems for its data. Resources must include hardware to support the project and, even more important, personnel support. An adequate programming staff is essential for a timely implementation of the system. If it takes too long to get anything functional, credibility is lost. Therefore, a phased implementation is the best method.

There must also be administrative support in developing links to the various other automated systems. Unless there is a single central information systems group, personnel from administratively separate departments may be assigned to work together in developing these system links. Therefore, it is essential that the project be supported by the central administration.

Our approach has been to get several basic components functional and in use in a prototype mode as soon as possible. This has allowed for user involvement at an early stage, and although it may have required additional customizations, we believe it has led to greater user satisfaction in the long run. We defined flow sheets, plots, and a link to the clinical laboratories as our initial basic functions. Since these basic functions have become operational, the users have been able to work with the system while further development proceeds in the glow of our increased credibility.

Project Summary We have outlined several categories of modifications: the expected, the unexpected, and the anticipated. Some of the modifications were expected; for example, we did not think that the laboratory would report results in exactly the same way it did at Hopkins, and we expected to have to redo the laboratory link. It turned out that there were many more unexpected modifications than we had anticipated. This was partly influenced by the fact that an information system was already in use on the Bone Marrow Transplant Unit. More correctly stated, the unexpected modifications were mostly due to user sophistication and expectations of the system. What may be acceptable to the naive user becomes unacceptable as the user has had experience with other systems and learns that there are other (often better) ways of doing things. But most important, it should be recognized that, although OCIS can be successfully ported to another institution, it is not a turnkey system. In order to have it implemented successfully, the institution must have an adequate level of support both financially and administratively.

So far we have implemented the clinical data part of the system, including flow sheets, plots, and unformatted data displays and the summary function, which provides a general description of the patient, including diagnostic information, patient admission information, protocol information, and BMT program-specific data. We also have many of the census reporting capabilities functional and a few of the basic search functions. Within the next six months we intend to implement the microbiology (BACT) function, the basic daily care plan function, and the abstract/tumor registry function. We do not plan to implement the hemapheresis or the pharmacy component at this point in time. After the basic clinical functions are implemented, we will begin implementing the outpatient appointment and research data management functions. We will also be evaluating the system to determine what additional functions are required and begin work on the areas of research we have outlined previously, specifically the daily care plan enhancements and the clinical care abstract.

We are about halfway finished with the implementation of the basic clinical functions that are part of the baseline system. This has been accomplished in about 18 programmer months by one full-time programmer with various levels of support on my part, depending on what other tasks needed to be accomplished at the time. Clearly, my past experience with TEDIUM has been a major benefit, but my experience with OCIS had been limited primarily to the daily care plan. Qur experience has shown that once the programming staff becomes proficient with TEDIUM, it becomes a tool with which any competent programmer can work more efficiently than with many other programming languages.

Clearly, OCIS and TEDIUM have provided a powerful and broad base from which we can develop a clinical information system to meet our needs. Unfortunately, the state of the art js sucli tliat no existing system can be immediately adopted without alteration. In our case we feel that the redesign and modifications we have made draw very heavily upon our ability to understand, develop, and implement a clinical information system tailored to the needs of the health professionals at The Arthur G. James Cancer Hospital and Research Institute, Ohio State University. Without OCIS, our job would be much more difficult and far more expensive; however, without this understanding, our job would be impossible.

References Barnett, G.O., Justice, N.S., Somand, M.E., Adams, J.B., Waxman, B.D., Beaman, P.D., Parent, M.S., Van Deusen, F.R., Greenlie, J.K., COSTAR System, in Information Systems for Patient Care, B.I. Blum, Ed., Springer-Verlag, 1984, pp. 270-292.

Friedman, R.B., Enitine, S., Murray, G.M., Hqjladay, D., Steinhart, C.E., An Integrated Clinical Protocol Management System, in Proceedings of the Third Annual Symposium on Computer Applications in Medical Care, IEEE Computer Society Press, 1979, pp. 81-84.

Horwitz, J., Thompson, H., Concannon, T., Friedman, R.H., Krikorian, J., Gertman, P.M., Computer-Assisted Patient Care Management in Medical Oncology, in Proceedings of the Fourth Annual Symposium on Computer Applications in Medical Care, J.T. O’Neill, Ed., IEEE Computer Society Press, 1980, pp. 771-778.

PROMIS Laboratory, Representation of Medical Knowledge and PROMIS, in Proceedings of the Second Annual Symposium on Computer Applications in Medical Care, IEEE Computer Society Press, 1978, pp. 368-400.

Serber, M.J., Mackey, R. and Young, C.W. The Sloan-Kettering Information System for Clinical Oncology, in Proceedings of the Fourth Annual Symposium on Computer Applications in Medical Care, IEEE Computer Society Press, 1980, pp. 728-730.

Stead, W.W., Hammond, W.E., Straube, M.J., A Chartless Record—Is It Adequate? in Proceedings of the Sixth Annual Symposium on Computer Applications in Medical Care, B.I. Blum, Ed., IEEE Computer Society Press, 1982, pp. 89-94.

Wirtschafter, D.D., Gams, R., Ferguson, C., Blackwell, W., Boackle, P., Clinical Protocol Information System, in Proceedings of the Fourth Annual Symposium on Computer Applications in Medical Care, J.T. O’Neill, Ed., IEEE Computer Society Press, 1980, pp. 745-750.

Рекомендуем к просомтру

www.kievoncology.com благодарны автору и издательству, которые способствует образованию медицинских работников. При нарушении авторских прав, сообщите нам и мы незамедлительно удалим материалы.