INTRODUCTION: A medical software application described by a requirements definition to document a history and physical examination of a child. Derived from research, and developed by design and prototyping. Data descriptions and sample screens will highlight key functions.
Foremost in methodology was testing and measurement to promote the refinement and usability of the design. An "Acceptability Test" or demonstration has been given to a random group of practicing pediatricians to gauge receptiveness, preferences, or dissatisfaction with the graphical user interface. Beta testing the application revealed different scenarios of use by multiple users. A resistance curve, analogous to the learning curve shows how a user incorporates the application into a work pattern in the clinical environment. Identification of recipients who benefit from the overall results and questions concerning the measure of success.
In a final discussion as a result of feedback and suggestions from outside sources, new function and improvement to base code is outlined that often predicts future development pathways.
METHOD: Based on research and identification of data that should be captured by the application, screen prototypes for pilot testing were developed. A specific goal was to insure that the user interface met certain specifications derived from the requirements definition in terms of efficiency and usability.
The prime method used to enforce the goal and refine the design for the better, was testing and measurement of various aspects of the user interface. Several testing scenarios were applied for different purposes. With a total of 8 screens and no initial deliberate pattern of testing, the method employed was to first do a general Black Box test paging through the screens and skipping forward or backward. Keeping in mind that the screen content was to have an ergonomic flow based on the assumption that history and physical data is taken in a certain order everytime, the second test was an opening up of the Black Box to a Clear Box with more specific details. Testing the over-all flow and ergonomic comfort of the interface indicated whether or not the grouping of data was presented in the right order. The third component of testing was at the lowest level of detail.
Testing the graphical user interface objects to approve or disapprove the usefulness and efficiency of specialized entry fields, multiple line entry fields, check boxes, etc. Experience told us to repeat the testing process and as time went on, the real estate problems on each screen were eliminated.
The last method is a "System Test" to measure the performance of the application against other means of documenting patients. Other methods include manual note taking, taking notes on forms, transcription and transcribing, or other in-house software applications. Efforts to measure the difference did not yield much precision. Comparing the application to other methods of documenting a history and physical is very subjective. As a result, a foot race type of test is not adequate. A time factor may be recognized, but other facets have to be considered such as how the system is used, what output is given when both systems finish and how much data is captured, as well as the quality or usefulness of the data.
RESULTS: Users must take a brief period of time to learn the screens prior to using the program on the job. Familiarity easily allows the user to assimilate the tool into clinical work patterns. Beta testing has helped in understanding how to evaluate the results of the System Test. Depending on how the application is used, the physician interview of the patient may be very short. Consequently, the history and physical record my also be short. However, when a complete history and physical is done from an extensive examination of the patient, the savings that accrue is better realized.
In another situation, more than one person might be taking data on a patient. For example, a nurse takes the peripheral data such as the vital signs, while the physician will write the history and chief complaint along with labs, impressions, and plans. Template Profiles used as a starting point on patients that have common symptoms also reduces the time required to document the patient. The Template Profile saves time as nothing parallels this in a manual setting.
Measuring is difficult because in a typical practice, a brief patient visit with a minor problem may not warrant the use of the application. On the other hand, where a trauma or a consult y a specialist is involved if a comprehensive work up is required, the application out-performs other means of documenting the patient. Without some consensus as to what constitutes a standard history and physical in terms of the minimum type of data that is acceptable, measurement is going to be arguable. Perhaps measurement can be deferred for the time being. The true measure might be for the recipients of the results. First and foremost, has there been an improvement in the care and health of the patient? For the physician, does the application free more time for analysis and diagnostics? For other medical staff, an accurate, clearly printed report facilitates carrying out the physician's orders without error. For the health care organization, an electronic document exists that can be placed into a larger document management system.
DISCUSSION: Evaluations by a random group of Pediatricians gave the application good marks, but the sum of all comments caused us to go back to make improvements and add more function. The provision for Template Profiles, supplemental screens for various specialists, and facsimile capability were ideas that were developed after general satisfaction with the screens was achieved. For example, the application is National Language Support (NLS) enabled. Initially the strings were bound to the executable. At the request of one client, we have bundled the strings as a separate dynamic link library module. Thus, end users can customize default data either tailored to a practice or as terminology changes without giving a specific order to the developer to accommodate the request. As client requirements become feed-back, further avenues of development become apparent. The implementation of a database engine makes the application feasible on a workstation which then supports record maintenance and return visits. In the future, the application may evolve into an excellent Client/Server application for larger organizations. At present, we have not explored other possible uses for this application, such as using it as an educational tool for patient case studies or for medical research were history and physical documents are uniform in content.
The following authors have influenced our thinking and we turn to their works for reference and refreshment periodically.
Mills, H., Linger, R., and Hevner, A. 1986. "Principles of Information System Design and Analysis." Orlando, FL: Academic Press.
Booch, G. 1994. "Object-Oriented Analysis and Design with Applications." Redwood City, CA: The Benjamin/Cummings Publishing Company, Inc.