Books by Jules J. Berman, covers

Berman JJ. Solving Quality assurance problems with object scripting 
languages. Artificial Intelligence in Medicine 3:161-171, 1991 

SOLVING QUALITY ASSURANCE PROBLEMS WITH OBJECT SCRIPTING LANGUAGES

Jules J. Berman

ABSTRACT

It is now possible for surgical pathology and cytology reports to be collected in a programming environment that permits a laboratory to answer all anatomic pathology quality assurance (QA) questions arising within the hospital. These questions may pertain to an individual clinician's ability to provide adequate specimens, to a pathologist's report turn-around time, to a cytology department's overall diagnostic accuracy, or to any aspect of pathology records. Most importantly, these questions can now be posed and answered as they arise, freeing departments of constraints imposed by commercially available anatomic pathology software packages. The necessary quality assurance expert system can be achieved through the use of object scripting languages that allow a programmer to treat reports and data fields as programmable units. In this report, the general properties of scripting environments are reviewed. Guidelines for using Hypercard as a prototypical programming environment for surgical pathology and cytology reports are provided along with sample quality assurance scripts.

key words: quality assurance, object oriented programming, script, Hypercard, Hypertalk, reports, cytology, surgical pathology, Toolbook.

INTRODUCTION

A pathologist in a large community hospital notices that there seems to be an increased number of inadequate cervical Papanicolaou smears received in her department. She would like to compare the rate of inadequate specimens received in the past three months with the rate received in the last three years. Further, she would like to know the percentage of inadequate smears contributed by each member of the gynecology department. A staff pathologist presents the case of a positive fine needle aspirate of thyroid at tumor board. The tumor board coordinator asks for the positive predictive rate of thyroid fine needle aspirates in the pathology department. The chief hospital administrator enters the office of the chief of pathology and requests the overall accuracy rate of surgical pathology and cytology reports to be ready for the Joint Committee of Hospital Accreditation the following week. The inspector for the Committee for the Accrediation of Hospitals has arrived. He would like to see a list of all the consultation cases sent by the department in the prior year.

The above problems are typical of the informational demands currently placed on pathology departments. Pathologists today are expected to be experts not only in their field of practice, but in all aspects of the reports generated within their departments. It is humanly impossible to answer quality assurance questions from memory, and it is impractical to maintain an investigative staff to sort through reams of reports on demand. Many pathology departments have chosen to purchase commercial anatomic pathology software, but it is naive to believe that a software package could be sufficiently versatile to answer all the questions that might arise in a department. Most commercial anatomic pathology software vendors prohibit purchasers from altering source code. Changes in the software requested by the purchaser usually involve recontracting with the software company to alter the program. How can a department search its files and prepare complete reports that answer questions not anticipated at the time that its software was designed? A solution to this problem is provided by object oriented program environments that treat reports and the data fields within reports as programmable objects. When a question arises concerning data in any group of reports, scripts can be written for objects, and instructions can be passed along an object hierarchy as the scripts are interpreted to produce an "answer object." Object scripting languages offer even the casual programmer (e.g., a pathologist or laboratory technician) an opportunity to devise software that performs exactly to his or her wishes.

SCRIPTING LANGUAGES

A property common to all scripting languages is the ease with which they can be used and understood, even by non-programmers. Presently, there are a variety of object scripting environments available for many types of computers. Hypercard, with its Hypertalk language, is an Apple product and is bundled in every Macintosh computer currently sold. Consequently, any quality assurance program using Hypercard is transportable to Mac Plus and higher models. A number of competing products designed for the Macintosh have recently appeared, including Supercard (Silicon Beach) and Plus (Olduvai).

Several PC compatible scripting enviroments have become available, including LinkWay (IBM) and Hyperpad (Brightbill-Roberts & Co. Ltd.). Ultracard (Intuitive Technologies) is a recently introduced program designed for the Amiga. With the introduction of Windows 3 (Micro-soft), a number of new scripting environments have appeared that not only provide alternatives to Hypercard, but which also allow some measure of portability between applications working under Windows 3 and Hypercard.

Toolbook (Asymetrix) is a an object scripting environment with a resident run-time version included in every Windows 3 package. This means that all Toolbook applications are immediately transportable to any computer that runs under Windows 3. However, Toolbook itself is not included with Windows 3 and must be purchased separately. Run-time versions of Toolbook applications would require Toolbook for users to make alterations in an application. One of the most important features of Toolbook is the feature of Dynamic Data Exchange (DDE), allowing information linking between Toolbook and other applications running under Windows 3. Heizer Software offers a utility (ConvertIt) that aids in transferring Hypercard applications to Toolbook. Unfortun-ately, at this time, conversions are not usually complete, requiring the user to finish off the last 20% or so of scripting changes needed to convert a Hypercard stack into a Toolbook application.

Spinnaker's Plus is a cross-system object scripting tool that is designed to support a variety of operating system platforms, including Windows 3, OS/2 Presentation Manager (Microsoft) and the Macintosh. This means that owners of all the platform versions of Spinnaker's Plus can move their Plus applications from PC's to Macintosh environments without altering any code. With Spinnaker's Plus for the Macintosh, one can import Hypercard stacks and reformat them for export to a PC.

Also available are a number of object oriented languages more suited for professional programmers. These include SmallTalk V (Digitalk, Los Angeles, California), Smalltalk-80 (ParcPlace Systems, Inc. Palo Alto, California), Eiffel (Interactive Software, Goleta, California), KnowledgePro (Knowledge Garden, Nassau, New York), object-oriented versions of C and Pascal, and numerous other resources. Although these languages are exciting programming tools, they require a high level of programming expertise, and would not represent a realistic option for the casual programmer.

As another alternative, commercially available databases can be used to store pathology data and to produce Quality Assurance reports based on queries posed by the user. Most of these data management systems are available in both PC and Macintosh versions. Toolbook and Hypercard can be used as front ends for data stored in large databases. Oracle for Macintosh (Oracle Corporation) uses a Hypercard front-end for the application. Omnis 5 (Blyth Software, Inc.) also provides Hypercard access. In this monograph, examples of Hypercard scripting will be discussed, as Hypertalk is by far the most widely used scripting language, with hundreds of books available for the novice. Furthermore, Hypercard has been tested by many thousands of users and has matured through a number of version updates (Hypercard version 2.0 has recently been released).

PATHOLOGY REPORTS ON HYPERCARD

Hypercard is a programming environment endowed with word-processing and graphic properties that allow users to present information in a visually appealing interface, linkable though buttons that permit navigation through related data fields. Many Hypercard features can be employed with Hypercard menu commands and buttons (without writing Hypertalk scripts), thus permitting non-programmers the opportunity to design their own applications. Other features are only available in the Hypertalk language used in scripting instructions to objects.

Information is contained in an ascending object hierarchy of buttons, fields, cards, backgrounds and stacks. Objects can be freely produced and customized, and every object can have a program (script) written that controls the way the object responds to environment messages (events). A stack is a collection of objects that work in concert as an application. CELLMATE is a Hypercard stack designed to produce cytology and surgical pathology reports and to document quality assurance activities [1]. It consists of a background (object) configured to resemble the standard U.S. Government Tissue Examination Form (SF-515, Figure 1). The background is constructed by using menu-selected graphic tools included with Hypercard. A simple background, such as that shown in Figure 1, could be constructed in under an hour. Cards are made by typing in data fields just as one would type in a paper form. Text that extends beyond the visible size of a field can be scrolled. Each field can contain up to 32 kilobytes of text [5,6]. When a card is complete, the user can go to a new (blank) card with the same background so that the next report can be prepared. The theoretical maximum size of a stack is 512 megabytes; a stack can theoretically hold nearly 17 million cards [5]. In Figure 1, the boxes are the data fields, and 18 fields are shown. Buttons are displayed in the lower portion of the card. A card can contain up to 32,000 card objects (buttons and fields) [5]. Objects can be either hidden or displayed according to their object script. Fields are objects that can be programmed to respond to user-initiated events. Any object in Hypercard (stack, background, card, field, or button) may have a script that customizes its functions as desired by the user. To write a script, the user pops up the blank scripting screen for the object to be programmed (all objects are programmable). Using the Hypertalk language, a program is written specifically for that object. Whenever a message is sent that is received by the object, the script executes. In most cases, the message that triggers an object to execute will be the mouse click over the object (e.g., a mouse click over a button will activate the button's script if the script commands itself to be activated by a mouse click). The script's execution is independent of any other object's script, although scripts can send messages to other scripts. The Hypertalk language is rich with commands that permit searches, mathematical operations, string manipulations, recursive procedures, and logical (Boolean) operations [5,6]. Hypertalk uses English words, and script statements can easily be understood by non-programmers (Tables 1, 2). In CELLMATE, a background script prompts the user to choose whether a cytology report or a surgical report is being prepared. This script executes when a command (message) is issued for Hypercard to create a new card (Table 1). A QA button has been scripted to pop-up selected fields used for quality assurance documentation when the mouse is clicked (message) over the QA button (object). The QA card is a hidden part of the report card and consists of QA fields that pop into view when desired (Figure 2). The report card and the QA card are part of a larger card that contains all the data fields (hidden and displayed), with visible fields restricted by the QA button's script. All objects can be customized to execute scripts that facilitate data entry. For instance the "accession number" field may have a next-in-line default that automatically advances accession numbers when new reports are created. The "pathologist name" field may have a password command that requires an electronic "signature" before an entry is made. The "diagnosis" field can be scripted to automatically type in a full diagnosis whenever the pathologist types in an abbreviated diagnosis (e.g., when the pathologist types "N", the script might enter "Negative for malignant cells" into the diagnosis field).

When a report is printed, the user can have all the visible card printed, or he can script selected fields to be included or omitted from the report print-out. Once a stack of cards has been entered, all data can be linked, extracted, and manipulated with the Hypertalk language. Hypercard version 2.0 includes new features that permit the user to assemble attractive reports from collected data fields in the stack.

FEATURES OF QUALITY ASSURANCE ACTIVITIES

The types of QA activities in hospitals may vary greatly. A hospital with only one pathologist will have different requirements than a hospital with a large staff of pathologists and screeners. Regardless, all QA programs must have certain features in common:

1. Indexing: Reports should be retrievable by patient name (or hospital identification number), by report number, and by diagnosis. Both surgical pathology and cytology reports should be available on the same indexing system, so that current material can be compared to past or future material. Hypercard supports thorough natural language searches than can extend to any fields in any stack. Commercial software for automatic coding by SNOMED or ICD-M is not currently available for any of the mentioned object scripting formats, but natural language searches may very well be a better search strategy than coded searches [3]. In addition, once a licensed copy of a preferred code list is obtained, it is feasible for a department to script its own coding program. 2. Documentation of Consultations and Reviews: A system for reviewing cases must be in operation. Some hospitals have every tenth case reviewed by a second pathologist. Other hospitals require a minimum number of cases sent for outside consultation. Cytology screeners are often asked to rescreen another screener's cases. Whatever the plan may be, review must be documented along with actions taken as the result of case review. 3. Follow-up Activities: When a cytology case is signed out with a diagnosis that would normally prompt further diagnostic action on the part of the physician that submitted the specimen, it becomes the responsibility of the cytology department to determine that additional material arrives. This serves both to check that the original cytologic diagnosis was correct and to insure that the patient is not lost to follow-up. In most departments, follow-up activity is largely confined to sending a reminder copy of the original report to the clinician if no further specimen on the patient is received in the department within a few months. 4. Quality Assurance Reports: Most hospitals in the United States have established offices of Quality Assurance. These offices monitor (often on a monthly basis) the QA activities of the various departments in the hospital. To comply with hospital QA requirements, Anatomic Pathology Departments are often asked to prepare a monthly report listing their QA activities.

All QA plans, particularly plans that establish monthly routines, will uncover certain types of errors but will miss other errors. For instance, a plan that calls for review of all positive cytologic diagnoses might detect a pathologist with an unacceptable rate of false positive diagnoses, but it will miss errors signed out by a pathologist who habitually undercalls his specimens (false negatives). A study that has every frozen section slide reviewed for accuracy of diagnosis may miss examining whether those frozen sections were submitted appropriately by the surgeon or whether the turn-around time for reporting frozen section diagnoses back to the operating room was unacceptably long. Clearly, it is impossible for QA to exhaustively examine all aspects of pathology practice that can be performed poorly. But whenever one QA study is chosen, other possible QA studies are excluded. The value of QA can be maximized by developing a different QA plan each month. For instance, in January, a department might review all Papanicolaou smears submitted by gynecologists to check for the percentage of unsatisfactory specimens (from the department as a whole and from each physician in particular). In February, a department may review all "inconclusive" fine needle aspirates from the prior September to see which patients were subsequently diagnosed within the department and whether the "inconclusive" diagnoses were justified.

The College of American Pathologists requires that cytology departments maintain statistical records of the percent normal, percent atypical benign, percent atypical suspicious, and percent positive reports [2]. Table 3 is a sample script written for a specially prepared statistics card (Figure 3). A user can always produce a current count of all the specimens in the department by clicking his mouse over the "DO TOTALS" button. The statistics card can also be printed with the touch of a button. Elaborate statistics can be scripted for all cases or for selected groups of cases.

PRACTICAL LIMITATIONS OF HYPERCARD

There are very few theoretical limitations to the use of Hypercard as a database manager. Handling close to seventeen million cards, each with up to 32,000 objects, Hypercard would seem the perfect answer to a pathology department's data storage needs. Unfortunately, Hypercard's lofty potential can be thwarted by hardware limitations. Because Hypercard loads an entire card (along with its entourage of objects, text, and graphs) into active (RAM) memory, the ability to run a Hypercard program is limited by available memory. As stacks get larger, routines that search or shuffle cards take longer and longer to run. For this reason, some programmers do not recommend Hypercard for large databases.

Hypercard 2.0 has improved stack performance by permitting scripts to be compiled (scripts in older versions of Hypercard were interpreted). In addition, searches in Hypercard can be speeded up by several orders of magnitude by preparing an index of search words, and a script can be written to index the location of every word in a Hypercard stack. Searches can be performed on the index, which in turn can link the index word to all locations in the stack where it appears. In this manner, Hypercard can store and access large databases. HyperHit (SoftStream International, Inc.) is a commercially available utility that produces an indexed file of card information for rapid data access. HyperSearch (Discovery Systems), is a set of external commands that permits searches through multiple stacks.

Gigabyte data storage is now available on CD-ROM, thus offering the opportunity for pathology departments to store files on compact discs, with reports retrievable by Hypercard. Hypercard's control over CD-ROM environment is one of the important new features of Hypercard version 2.0 [6]. An example where Hypercard is used as an information manager for a large database is Metacard, the browser for multiple data sources provided by the National Library of Medicine [4].

Finally, it is prudent for pathology departments to purchase a fast computer. This does not mean that departments need to buy a mainframe system. Top-of-the-line Macintosh computers and PC's using Intel's 486 CPU are sufficient for the QA needs of any pathology department. Of course, the outlook for the future is that microprocessor-based computers will continue to evolve as faster machines.

LOADING EXTERNAL DATABASES INTO HYPERCARD

One of the most important barriers in medical informatics is the complex problem of sharing data held in a wide variety of software formats and operating systems. DVA File Manager is the medical informatics software used by most U.S. government medical facilities. If a pathology department has been loading its reports for years into File Manager, any thought of converting files to Hypercard would necessitate file exchange and translation between incompatible systems. In the pathology department of the Baltimore Department of Veterans Affairs Medical Center, anatomic pathology report files were downloaded from a Digital Equipment Corporation VAX to a CompuAdd 386 personal computer. The downloaded file was formatted for Macintosh (using Apple File Exchange) and converted to a Wordperfect file. Using Hypercard's read file command, individual reports were read into cards on a Hypercard stack. Although these steps required skill beyond those used in operating Hypercard, they demonstrate the feasibility of transporting external report files into Hypercard.

CONSIDERATIONS BEFORE CHOOSING ANATOMIC PATHOLOGY SOFTWARE

Costs of computer hardware are falling. In addition, personal computers have attained sufficient speed and memory to handle large databases (previously the exclusive realm of mainframes). The cost of pathology software, however, is still quite high. The most popular anatomic pathology software applications sell for approximately $150,000, and the users of these systems consider the cost small compared to the value of such systems to the hospital. In comparison, Hypercard's retail cost is $49 and is bundled free with all new Macintosh computers. Other Hypercard-like environments for Macintosh or PC's range in cost from $100-$600. Relational database programs are somewhat more expensive, ranging from $200-$1,000. The most important expense involved in using object scripting environments is the time spent by the pathology staff in customizing the Hypercard to the department's needs. Scripts must be written to insure the overall security of the system. Hypercard contains password and encryption features that can be used to restrict access to Hypercard or to limit a user's freedom within Hypercard (a user can be limited to reading reports), and can require an electronic signature for releasing reports or entering the name of a pathologist on a report. Procedures must be established to insure that back-ups of all data exist (probably in the form of disks and paper copy prepared on a daily basis). A Local Area Network may need to be established to allow clinicians access to datafiles. File sharing may need to be established with the hospital's mainframe computer. These functions traditionally have been the exclusive domain of the systems operator, a person trained to make sure that a computer system works smoothly without loss of data and with minimal down-time. The hidden cost of Hypercard-like environments is the time and expertise needed to implement them. The hidden value of Hypercard-like environments is that once implemented, Hypercard is customized specifically to a department's needs and can be changed as the needs of the department change.

SUMMARY

Scripting languages provide pathology departments with an economical means of entering pathology reports into an environment that a casual programmer can master. Central to all scripting environments are the presence of objects that can be easily created, contain text or numeric data, that can be controlled by programs written for the object (scripts). The accessibility of object scripts permits post hoc manipulation of data fields, resulting in facile generation of QA reports. A wide range of support software is also available that facilitate report generation and mainframe interfacing. Key to the successful use of these environments are personnel who have facility with a scripting language and who also have an understanding of the Anatomic Pathology data requirements in the hospital. Figures 1,2,3 illustrate template cards that can be freely used by departments wishing to construct an anatomic pathology Hypercard stack. Listing 3 provides the script for the QA statistics card shown in Figure 3.

CAPTIONS

Figure 1. A background card for surgical pathology and cytology reports. Boxes with double arrows on their right edge are scrolling fields that can hold up to 32 kilobytes of text or graphics. Buttons are placed, in this example, at the bottom edge of the card. When the mouse clicks on a button, a script is initiated or a navigation command is executed.

Figure 2. The QA card. This card is produced without leaving the report card by overlaying previously hidden QA fields (Prior Patient Diagnoses, Cytotech Diagnosis, Concurrence and Actions Taken) over the report background.

Figure 3. The statistics card. Clicking the mouse over the "DO TOTALS" button sends a message to the button initiating a script (list 2) that computes and enters data into the appropriate card fields.®PG¯

TABLE 1. SCRIPT OF BACKGROUND LAYER OF REPORT CARD
ON NEWCARD
      ANSWER "SURGICAL OR CYTOLOGY SPECIMEN" WITH "SURGICAL" OR
      "CYTOLOGY" -- prepares a dialog box that prompts the user for
                    information when a "new" card command message is
                    received
      IF IT IS "SURGICAL" THEN PUT "S-89-" INTO BACKGROUND FIELD ID 8
      IF IT IS "CYTOLOGY" THEN PUT "C-89-" INTO BACKGROUND FIELD ID 8
      CLICK AT THE LOC OF BACKGROUND FIELD ID 8 -- 	puts the cursor in
                                                    the accession field
END NEWCARD


TABLE 2. SCRIPT OF CARD BUTTON "DO TOTALS"
ON MOUSEUP -- script responds when the mouse clicks on the "DO TOTALS"
              button
  LOCK SCREEN -- locks the screen for the duration of the script so
                   that the user doesn't see the card shuffling
                   performed by the script
  SET LOCKMESSAGES TO TRUE -- allows cards to ignore system messages
                                during  script operation

  SET THE CURSOR TO 4 -- makes visible the figure of a wristwatch,
                           alerting the user that a script is in
                           action
  PUSH CARD -- saves the current card so that it can be retrieved at
                 the end of the script
  PUT EMPTY INTO IT
    PUT EMPTY INTO CYTOCOUNT
    PUT EMPTY INTO SURGICOUNT
    PUT EMPTY INTO POSICOUNT      --declares new containers and sets
                                    their contents to zero
    PUT EMPTY INTO NEGICOUNT
  PUT EMPTY INTO INCOCOUNT
    PUT EMPTY INTO SUSPICOUNT
    PUT EMPTY INTO UNSATICOUNT
    GET THE NUMBER OF CARDS -- determines the number of cards in the
                               stack and
                               puts it in the it" container

    PUT IT-1 INTO CARDCOUNT -- saves the specimen number in a newly
                               declared  container, CardCount
    REPEAT FOR CARDCOUNT -- recursive command that adds the
                            positive,negative, inconclusive,
                            suspicious and unsatisfactory
                            diagnoses and places them into containers.
       DEMENU "NEXT"

       IF FIRST CHAR OF BACKGROUND FIELD ID 8 IS "C"  
   THEN ADD 1 TO CYTOCOUNT
   IF FIRST CHAR OF BACKGROUND FIELD ID 8 IS "S"  
   THEN ADD 1 TO SURGICOUNT
       IF FIRST CHAR OF BACKGROUND FIELD ID 10 IS "P"
       AND FIRST CHAR OF BACKGROUND FIELD ID 8 IS "C"
       THEN ADD 1 TO POSICOUNT
       IF FIRST CHAR OF BACKGROUND FIELD ID 10 IS "N"
       AND FIRST CHAR OF BACKGROUND FIELD ID 8 IS "C"
       THEN ADD 1 TO NEGICOUNT
       IF FIRST CHAR OF BACKGROUND FIELD ID 10 IS "I"
       AND FIRST CHAR OF BACKGROUND FIELD ID 8 IS "C"
       THEN ADD 1 TO INCOCOUNT
       IF FIRST CHAR OF BACKGROUND FIELD ID 10 IS "S"
       AND FIRST CHAR OF BACKGROUND FIELD ID 8 IS "C"
       THEN ADD 1 TO SUSPICOUNT
       IF FIRST CHAR OF BACKGROUND FIELD ID 10 IS "U"
       AND FIRST CHAR OF BACKGROUND FIELD ID 8 IS "C"
       THEN ADD 1 TO UNSATICOUNT
    END REPEAT
    POP CARD
    PUT CARDCOUNT INTO CARD FIELD "TOTAL NUMBER"
    PUT SURGICOUNT INTO CARD FIELD ID 2 -- instructs containers to
                                           fill the proper fields

    PUT "  . . . (" & SURGICOUNT/CARDCOUNT & ")" AFTER CARD FIELD ID 2
    PUT CYTOCOUNT INTO CARD FIELD ID 3
    PUT "  . . . (" & CYTOCOUNT/CARDCOUNT & ")" AFTER CARD FIELD ID 3
    PUT POSICOUNT INTO CARD FIELD ID 6
    PUT "  . . . (" & POSICOUNT/CYTOCOUNT & ")" AFTER CARD FIELD ID 6

    PUT NEGICOUNT INTO CARD FIELD ID 7
 PUT "  . . . (" & NEGICOUNT/CYTOCOUNT & ")" AFTER CARD FIELD ID 7
 PUT INCOCOUNT INTO CARD FIELD ID 8
  PUT "  . . . (" & INCOCOUNT/CYTOCOUNT & ")" AFTER CARD FIELD ID 8
    PUT SUSPICOUNT INTO CARD FIELD ID 9
  PUT "  . . . (" & SUSPICOUNT/CYTOCOUNT & ")" AFTER CARD FIELD ID 9
    PUT UNSATICOUNT INTO CARD FIELD ID 10
  PUT "  . . . (" & UNSATICOUNT/CYTOCOUNT & ")" AFTER CARD FIELD ID
    10

 UNLOCK SCREEN -- returns the screen to the user
 SET LOCKMESSAGES TO FALSE -- allows system messages to be read by
    Hypercard
END MOUSEUP


REFERENCES

[1] Berman, J.J., Moore, G.M.: Cellmate: prototype hypercard stack for anatomic pathology quality assurance. Fourteenth Annual Symposium on Computer Applications in Medical Care. IEEE Computer Society Press, Washington, 1990, pp.1005-1006.

[2] College of American Pathologists Commissions on Laboratory Accreditation Inspection Checklist. Section VIII. Anatomic Pathology and Cytology, Skokie, Illinois, 1989.

[3] Friedman, B.A.: The impact of new features of laboratory information systems on quality assurance in anatomic pathology. Archives of Pathology and Laboratory Medicine 112 (1988) 1189-1191.

[4] Nelson, S.J., Sheretz D.D., Tuttle M.S., Erlbaum, M.S. Using Metacard: a Hypercard browser for biomedical knowledge sources. Fourteenth Annual Symposium on Computer Applications in Medical Care. IEEE Computer Society Press, Washington, 1990, pp.151-154.

[5] Waite, M., Prata, S., and Jones, T.: The Waite Group's Hypertalk Bible. Hayden Books, Indianapolis, 1989.

[6] Winkler, D., Kamins S.: Hypertalk 2.0: the Book. Bantam Books, New York, 1990.®PG¯

Page last modified December 18, 2012