The TDS [#!TDS77!#] health care system supported many health care applications including order entry, result reporting, medication tracking and scheduling, vital signs, flow sheets, active patient care, nursing support systems, day-to-day management of a patient while in the hospital, short term medical information, laboratory orders and result reporting, pharmacy, and day-to-day charting.
This system was built by Lockheed in the mid 1960s as a spin off of the space program. Congress wanted to show that the same technology advancement that landed a person on the moon could also have down to earth applications. The first customer was a medium sized local hospital: El Camino Hospital.
The original Lockheed team had several hundred members and it took several years to build the base system. It took several more years of hospital testing to make the system useful and to establish high quality.
The architecture was tool based. In this tool based architecture, the system was built around several authoring tools. One tool was used to author formularies and list. Another tool was used to author application logic and presentation, while another tool was used to author database records. A general purpose database and user interface engine was provided. The content was authored by the tools and then interpreted by the database. These and the user interface engine defined the application.
The applications were split into two halves. One half of the application defined the database while the other half of the application defined the application logic and the user interface. In fact, it would be more accurate to say that the user interface defined the application logic. This was a client/server architecture with fat clients. Note that the GUI was displayed on dumb monitors and the client ran on the mainframe.
The database, called M1, was influenced by MUMPS. The underlying structure of the database resembled artificial intelligence frames. Every record could have a variable number of fields with each field having a facet. A facet defines how the field of the record is to be obtained. A value facet would contain the data. A function facet would contain an algorithm to calculate the data. Other facets included domain checks, pre-conditions, post-condition, format information, and triggers. The trigger facet was used to notify other associated records that a change in this data record has occurred. Records need not have the same scheme nor be complete. A tool was provided to manage the database. Features included the ability to view, update, delete, and create the data.
The user interface, called M2, was also frame-based. One frame equals one screen. The fields on the screen were controlled by the facets in the frames. These facets governed display information, application logic, entry format constraints, default values, and screen navigation. A customer would click through screens and complete a database frame. Once the frame was completed, the customer would save the frame. The act of saving the frame may trigger other actions. A tool was provided to build and manage frames.
The system had several technology innovations for the mid 1960s. These included customixed light-pen, light-sensitive monitors, and networking cards. The system was hand-crafted in assembly code.
Included with the system was an example hospital. This included several thousand screens which represented several dozen health care applications. The system took about a thousand person years to build and stabilize for the first hospital. Several more thousands of person years were invested to clone the system into about 100 other hospitals. Since this system was very expensive, millions of dollars per hospital per year, only the largest hospital could afford such an investment. Each customer required extensive training of several person months.
Once the system was built, many other hospitals could be cloned from the original. Hospitals, and health-care in general, are about the same. They differ on details of content but not so much on difference of functions. For example, every hospital has a pharmacy where prescriptions are filled but the exact formulary differs greatly.
El Camino Hospital played a critical role as the very first customer. El Camino Hospital provided high quality domain knowledge and acted as testers. By having the system active in a working hospital gave credibility to the system and raised the level of trust.
This system was stable for thirty years. The tool-based architecture allowed for new content, new screens, and new application logic. The frame-based system allowed for flexibility of information. After initial development, the system was moved from a NASA project to a company. Individuals were given the option to follow the project or to stay in the company.
The software engineering methodology was cyclical. Small changes were introduced, tested in the example hospital, released to the customer, errors were incrementally fixed, and new applications were incrementally developed.
The original team did not generate a requirement document nor an architecture document. The original key individuals did not follow the system into productization. The remaining team focused on content while the underlying tools and infrastructure remained stagnate. Technology changes soon made the underlying infrastructure obsolete. Attempts to change the infrastructure had the affect of converting the code from a stable base to a fragile tangle of spaghetti code. The product disappeared in the late 1990s.
The tool-based architecture along with the underlying frame-based data model allowed the product to reflect changes in content. The custom hardware, lack of requirement and architectural knowledge, hand-crafted assembly code, and loss of key individuals contributed to the product obsolescence.
The cyclical software engineering methodology generated a well focused, hospital-base, short-term clinical information, nursing system but missed the bigger pictures of including doctors, administration, and the electronic patient chart.
See tables 7.3
and 7.4 starting on page
![[*]](cross_ref_motif.gif)
.
|