-~tll

BiMledical
ELSEVIER SCIENCE
lRELAND
International Journal of Bio-Medical
34 (1994) 59-76
Computing Computing

Functional requirements as an integral part of the

design and development process:
summary and recommendations

Robert A. Greenes*“, Morris Collenb, Roger H. ShannonC

‘Department of Radiology, Harvard Medical School, Brigham & Women’s Hospital, 75 Francis Street,
Boston, MA 02115, USA
bDivision of Research, Kaiser Permanente, Oakland, CA, USA
‘Veteran’s Health Administration, Durham, NC, USA

Abstract

The Health Care Professional Workstation (HCPW) provides a portal to the health care
system as a whole. Through this portal the health care professional must be able to carry out
a wide variety of tasks in an integrated fashion. Traditional health care information systems
have not been designed to support this kind of use, so the functional requirements develop-
ment process must be capable of leading to an architecture and components for a system that
will support such use. A variety of approaches may be employed to develop functional re-
quirements, which may be used singly or in combination. Recommendations for this activity
center on domain delineation, evaluation efforts to establish the most effective approaches,
detailed functional requirement development, evaluation of the developed functional require-
ments, creation of shared resources, and education and training in the use of the tools and
methodologies.

Key words: Functional requirements; Health care professional; Workstation; Health care
information system

1. Introduction

The increasingly complex health care delivery systems of the 1990s impose on
health care professionals a greatly increased need for efficient information process-

* Corresponding author.

0020-7101/94/$07.00 0 1994 Elsevier Science Ireland Ltd. All rights reserved.

SSDI 0020-7 IO1 (94)00898-R
60 R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76

ing. The evolving workstations of the 1990s have extraordinary technical potential
for satisfying the needs of such users. However, to be able to effectively use a tech-
nology, that technology must be designed or adapted to meet the users’ needs. To
design a suitable technology for a user, the user must explicitly specify for what func-
tions the technology is to be utilized. The more complex and costly the technology,
the greater is the need for users to specify detailed, exact functional requirements.
The domain of interest is the entire health care delivery system, which includes the
patients, all health care clinical professionals, administrators, and health care policy
makers, as well as other health care workers; contexts include homes, offices, hospi-
tals, and extended care facilities. Nonetheless, we focus here only on the subdomain
characterized by the needs of the health care professional, and those functions in-
itiated by, or directly interacting with, such an individual, and not on second-order
and more distal functions. For example, if a physician admits a patient, the various
tasks of the admissions office other than those that relate directly to the health care
professional are not considered herein.
In this report the use of the term ‘health care professional’ is intended to include
individuals functioning in such capacities as physician, dentist, nurse, pharmacist,
administrator, researcher, policy analyst, or educator.
Some other considerations are important to the process of defining functional
requirements for an information system in a domain as complex as health care:

(i) The entire health care ‘enterprise’ is itself undergoing change, not only as a
normal, continuing process of evolution, but as a result of a current sense of
cost crisis which may result in more dramatic alterations of the enterprise. As
a consequence, the process of developing information system requirements
should not be considered so much as focusing on relations among an existing
set of individuals, organizations, and institutional entities. Rather it should be
considered in terms of a set of tasks, roles, and responsibilities that must be
carried out. The mapping of these to actual entities should be considered
separately.
(ii) An implication of the above is that the development of functional requirements
is not a one-time process, carried out at the outset of an implementation effort.
Rather it is an integral part of the information system design and development
process. The mapping of functions to entities is an iterative task, in which both
the functional requirements specifications and the tasks, roles, and respon-
sibilities of entities are continually relined.

Existing information systems have been largely developed in a ‘vertical’ fashion

to perform specific sets of tasks on particular kinds of data. Yet the professional in-
dividual is typically a problem solver, requiring the ‘horizonal’ integration of infor-
mation (data and knowledge) from a variety of sources, and the ability to perform
any number of problem-specific information tasks [l].
The Health Care Professional Workstation (HCPW) is not considered to be a box
or physical entity, but rather only an entity in a metaphoric sense, in that it
represents a portal through which the professional user interacts with other entities
in the health care information system. Consideration is given to what functions
R.A. Greenes et al. / Ini. J. Biomed. Comput. 34 (1994) 59-76 61

... Fam.MD 0.. Surgeon ?? ** Radiologist *a

?? NllIse

J
Fig, 1. Vertical orientation of many current systems - making integration across systems difficult.

should be carried out via this portal. Furthermore, we consider this portal to be
available to the health care professional wherever he or she is located when perform-
ing an information task, not anchored to a fixed location. The idea of a workstation
as the locus through which integration of information and performance of problem-
specific tasks are done forces one to consider many new kinds of possible inter-
actions. Fig. 1 illustrates the current status, whereby particular kinds of users

... Fam.MD ?? ** Surgeon **

?? Radiologist ?? ** Nurse

Fig. 2. Task-oriented view ~ requiring horizontal integration.

62 R.A. Greenes et al. / Ini. J. Biomed. Comput. 34 (1994) 59-76

interact with vertical systems and in which integration is difficult. Fig. 2 shows the
trajectories through a variety of information tasks that might ideally be performed
by professional users. To the extent that functional requirements can be turned into
specifications for information services to carry out specific kinds of tasks, these ser-
vices can be implemented as ‘components’ and perhaps offered independently. Some
may be of value to more than one kind of user. The resultant reusability of com-
ponents may be a primary advantage of adopting this perspective.
By offering software components that perform specific information services, a
wide range of choice is provided to the system builder, who is able to implement a
system by selecting and integrating the appropriate components. Based on the nature
of the component information services, their inter-relations, and the quality of their
implementations, these services may be offered on the marketplace either singly or
in combination. Such combinations, as shown in Fig. 3, need not necessarily corres-
pond to existing information systems.

2. Approaches (methodologies and tools) for development of functional requirements

In considering alternative methods for developing Functional Requirements

(FRs) that can be most effective for creating design specifications for information
systems, some important definitions are provided in Appendix C. A variety of
approaches have been used to develop FRs, including the following: experience; use
of literature; brainstorming; consensus development; strategic planning (top-down,
going from vision to goals to objectives); focus groups; iterative interview (expert
debriefing); prototyping; program instrumentation (to determine what people actu-
ally do); and machine learning (to evolve system behavior directly from actions).

Admin **
?? Fam.MD 0.. Surgeon **
?? Radiologist **
?? Nurse

Fig. 3. Component-based architecture - components that are provided are a direct result of functional
requirements process, and their interactions with other components are clearly defined.
R.A. Greenes et al. /hr. J. Biomed. Compur. 34 (1994) 59-76 63

These are not mutually exclusive, and may be used in combination. For example,
focus groups, experience, and consensus development are often used together.
Formal methods exist that address the entire lifecycle of systems, including pro-
cesses of analysis, requirements development, specification, design, implementation,
testing, documenting, and updating. Lifecycle approaches include Software Analysis
and Design Technology (SADT) - Waterfall and CASE methods, Scenario-based
Engineering Process (SEP), and the Spiral method. The SEP process described in
Ref. 2 is an example of a Domain-Specific Software Architecture (DSSA) approach
[3]. Three of these approaches to development of requirements are illustrated herein:

2.1. Literature
Published papers can provide useful suggestions’for FRs, from the points of view
of the authors. .This Workshop included solicited papers with perspectives provided
by government planners, primary care providers, clinical specialists, nurses, and
researchers. Appendix A provides summaries of some perspectives taken from
selected representative papers.

2.2. Expert experience and consensus development

This is one of the most common methods for developing FRs. The FRs presented
in the first list in Appendix A were gleaned initially from Workshop papers, and
were then further refined and consolidated through discussion and consensus
development by the working group.

2.3. Scenario-based Engineering Process

The Scenario-based Engineering Process (SEP) is a DSSA methodology (see
Appendix C, Useful Definitions), which examines multiple scenarios to develop an
increasingly refined domain model. The domain model defines the objects involved,
the services they perform, and the attributes of the objects. Scenarios may follow an
activity as it involves multiple participants, or may consider different activities for
a particular participant. As each new variation of participant or activity is con-
sidered, the developing domain model is increasingly refined. Methodology is
described in detail in a companion paper [2].
In the SEP process, typically requires one to do the following:

0 describe scenario;
0 mark significant events;
0 identify important healthcare tasks or process steps;
0 analyze each task;
?? characterize each resource;
0 map technologies to resources; and
0 assign responder to each technology resource.

‘Tasks’ become ‘requirements’ in the user’s terminology. Events characterize

inputs to the responder.
Appendix B describes three related scenarios and provides an example of a portion
of the analysis of one of them.
64 R.A. Greenes et al. /hi. J. Biomed. Compur.34 (1994) 59-76

3. Criteria for evaluating or selecting processes

The following desiderata are representative of criteria that should be considered

in selecting approaches for developing the FRs for an HCPW.
Updatability: the specification of FRs is readily modified to reflect changing
needs.
Frameability: the context and constraints pertaining to FRs are explicit.
Generatability: the FRs can be readily turned into design specifications, perhaps
automatically.
Reusability: FR specifications are done in such a manner that FRs for similar
activities can be adapted from them, through abstraction and generalization.
Relation explicitness: dependencies such as time or state are explicitly defined.
Correctness: the FRs can be established to be correct in that they are internally
consistent.
Completeness: all conditions and states are modeled.
Clarity: the FRs are able to be understood by human users.
Signoff a process is defined for determining when the FR set is ready for use in
design.
Utility: the FR development process is regarded by human users as practical and
effective.

4. Functional requirements (FRs) for health care professional workstations (HCPW)

To produce in a few days an actual comprehensive listing of FRs was considered

to be unrealistic, since there are so many needs for all the various users of HCPWs.
Furthermore, the FRs continually change to satisfy innovations in clinical medicine.
However, as noted above, listings of selected FRs were assembled by consensus of
the working group, and also from the papers submitted by participants in this work-
ing conference. These listings, in Appendix A, should be considered only as a start-
ing point of an FR development process.

5. Recommendations

5.1. Short-term (2-3 years)

(I) HCP W subdomain delineation. Health care information systems must support
all sectors of the health care delivery system. To develop a set of Functional Require-
ments (FRs) for the Health Care Professional Workstation (HCPW), it is recom-
mended that a comprehensive domain model be broadly developed, within which the
subdomain of the HCPW is delineated.
(2) Definition and evaluation of FR development approaches. It is recommended
that alternative approaches be explored actively through demonstrations, pro-
totypes, testbed applications, etc. Criteria for evaluation should be established, both
for the development approaches and for the FRs produced by those approaches.
(3) Development of FRs. It is recommended that a comprehensive set of FRs
for the HCPW in different environments be developed, noting commonalities and
unique aspects.
R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76 65

(4) Evaluation of FRs. Using well-defined criteria (Recommendation 2) it is

recommended that the FRs developed be evaluated through demonstrations, pro-
totypes, testbed applications, etc.
(5) Shared libraries. It is recommended that shared libraries be established con-
taining development approaches, scenarios, definitions, tools, criteria, FRs, etc.
(6) Education and training. It is recommended that education and training needs
for carrying out the FR development process be determined, and that procedures
and facilities for implementing them be established.

5.2. Long-term (4-5 years)

(1) Re-evaluation of FR developmentapproaches. It is recommended that, based
on results of experience as well as evolution of methods, re-evaluation of FR de-
velopment approaches be carried out. This is actually an iterative process, since it
is not expected that approaches will remain static.
(2) Update/revision of FRs. As evolution of the health care system occurs and
technology innovations evolve, it is recommended that the FRs be updated and/or
revised as appropriate.
(3) Expansion of libraries and of education and training support. As useful
resources, tools, and techniques become established, it is recommended that these
services be made more widely and systematically available and that the necessary
education and training to be able to use them effectively be expanded.
(4) Standards for integration. Based on experience, disparate but valuable
approaches are expected to evolve, not only for the HPCW subdomain but for other
subdomains. It is recommended that efforts be focused on developing standards to
permit merging of these approaches and domain models.

6. Conclusions

The Health Care Professional Workstation (HCPW) is an important technology

focus, because it must provide a kind of functionality that is not well met by most
existing health care information systems. A focus on the HCPW forces consideration
of functionality that crosses traditional system boundaries by requiring a kind of
horizontal integration of information resources that such traditional systems cannot
typically provide. The HCPW thus provides a tangible embodiment of a break-the-
mold approach to functional requirements development.
As one considers the inter-relationships of components necessary to satisfy the
needs of the HCPW, and the complexity and evolving nature of the health care
system itself, it should be apparent that the creation of a set of Functional Require-
ments (FRs) cannot be a static process that is carried out once at the beginning of
a system design and development cycle. Rather, the FRs should become an integral
part of the system design, being continually refined as the system developsand new
relationships and requirements become identified.
Emerging DSSA system design and development methodologies offer the poten-
tial to provide specifications for complex systems such as those necessary for health
care in terms of components and their inter-relationships. The integration of the FR
66 R.A. Greenes et al. /ht. J. Biomed. Compur. 34 (1994) 59-76

creation process with such newer methodologies may facilitate the update, refine-
ment, and more cost-effective implementation of health care information systems.

7. Acknowledgments

The discussions and ideas of the members of the Functional Requirements group
were essential in developing this synthesis. Particularly valuable were the contribu-
tions of D. DeBrota, K. Harbison and S. Hufnagel, who provided useful summaries
and additional materials, upon which the Appendices are based. Thanks are also due
to E. Mettala, R. Bryant and J. Kouwenberg for their contributions. The authors
of this paper accept responsibility for changes made to the original materials.

8. Appendix A. Selected functional requirements derived from literature review, expert

experience and consensus development

The following lists of functional requirements are representative of the kinds of

requirements that will need to be considered, in more specific detail, across many
categories of professional users. Notes are explanatory or illustrative. The first list
was prepared by a workshop participant by summarizing various contributed
papers, and was then refined by discussion and consensus development based on the
experience of the participants. The other lists are brief summaries of the views of par-
ticular authors of contributed papers.
These lists are presented in the hopes that they may prove useful as a starting point
for future efforts which seek to more completely define functional requirements for
health care professional workstations. The individual functional requirements within
a list are not presented in any particular order of importance. Some requirements
are ‘musts’ while others constitute ‘would likes’ at the time of the list’s creation.
There is redundancy among the requirements within some lists and among the
various lists. Clearly, with time, the relative importance of various requriements is
expected to change, new requirements are expected to be identified, and present
requirements are expected to be modified, replaced, combined, or eliminated com-
pletely. Furthermore, many of the functional requirements in the lists conflict with
one another such that design tradeoffs will be necessary (at least within the limits
of technology available today) if one attempts to satisfy all of these requirements
simultaneously.

From D.J. DeBrota (adapted from summary of various workshop papers and con-
sensus discussion):
Authentication: Is the individual definitively identified?
Authorization: Is the individual permitted to perform the function?
Faithfulness (from W. A. Nowlan [3]): Models for information content, process, and
inference that are unambiguous.
Information capture from provider at point of interaction: Avoidance of redundancy.
Unobtrusiveness: Non-interference with the ability of the provider to focus upon the
patient and the patient’s needs.
R. A. Greenes et al. / Ini. J. Biomed. Comput. 34 (I 994) 59-76 61

Net cost/benefit advantage: Increase in provider and/or system productivity or quali-

ty of care provided.
‘Virtualpatient record’: Integrated access to patient data, possibly residing on multi-
ple disparate systems.
Consistency of interface
behavior in different HCPWs.
Predictability: System in state it was last left? Clinician sense of being in control.
Integrity: Accessed data represent their actual true current state.
Accountability/audit trail.
Maintenance of privacy and confidentiality of patient data.
‘Undo’ capability: Anything up to point of ‘commit’? Need to generate entries to pro-
vide an audit trail.
User empowerment: Usage intuitive; customizable; easy exits from any level;
judicious use of mandatory fields; navigable (no restriction to linear or hierarchi-
cal sequence of functions/tasks).
Scalability/applicability/adaptability: to hardware/software platforms of varying
capability.
Support for quality assurance tasks: Protocol/guideline compliance monitoring.
Decision support: Increased provider awareness to abnormal or exceptional condi-
tions (e.g., ‘alerts’, highlighting abnormal lab values); support for practice
guideline compliance.
Functional integration across tasks: Clinical data passable to diagnostic tools, then
to guidelines, then to orders.
Support for outcome measures.
Support for patient tracking.
Support for follow-up reminders.
Access to external knowledge bases, references, education materials.
Support for analysis of clinical databases.
Ubiquitous access: Resource access not location-dependent, e.g. hospital, home, of-
lice; single logon to all resources needed.
Work with legacy systems.
Work with emerging systems.
Communication support:Coordination of care providers with other care providers;
subsumes E-mail,voice mail, video mail, etc.
Watchdog capabilities: Monitoring and alerts (from J.J. Nobel [4]) for inappropriate
test performed; test performed inefficiently; appropriate test not performed;
unnecessary duplication of test; test performed inaccurately; faulty test interpreta-
tion, patient not informed and involved; inappropriate therapy initiated; appro-
priate therapy inititated inefficiently; baseline state not adequately recorded;
components and timing of intervention not adequately recorded; outcome not
adequately recorded; failure to appropriately aggregate, interpret and provide
access to evaluation data; failure to provide feedback to practitioners.
Multimedia support: Graphing/visualization of data.
Support for clinical research: Upload/download data to relevant clinical databases;
analysis capabilities.
Support for derivativefiles: Personal reminder tiles, research files, teaching tiles, etc.
Productivity applications: Clinician’s calendar.
68 R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76

Support for multi-tasking using appropriate metaphor(s).

Dynamic updating of data: On-line linkage to data generators.

From R. Bryant (see acknowledgements):

User identification facilities that allow the user to register with the system rapidly,
conveniently and consistently.
Responsive system able to provide support in the timeframes demanded of clinical
practice.
Input mechanisms appropriate to the level of knowledge of the user and to the task
being carried out.
Physical input/output devices appropriate to the users’ requirements and the cir-
cumstances of use (use at the point of care may require a high degree of por-
tability).
Information display in a form and at a pace suitable for the users and their current
tasks, including feedback appropriate to the users and their tasks (note that this
implicitly suggests the use of multimedia output).
Facilities that allow users to tailor or customize their workstation services to suit their
needs in different task scenarios.
On-line support in the form of appropriate help and error messages.

From P.C. Carpenter [S]:

Full access:
?? In all examining room settings and in a variety of the places related to a medi-
cal desk.
?? At the hospital room or emergency treatment unit. Additional considerations
include whether portable or fixed workstations are most appropriate.
?? A variety of places including the nursing station, corridor sites, conference
rooms and lounges, dictation carrels, etc.

Unobtrusiveness: Rapid access to specific information without significantly breaking

off attention from the patient. The physical presence of the computer system in
the patient care setting should not intrude on the physician/patient interaction.
Information presentations should be naturally screened from the patient’s view,
but it should be easy to enable the patient to see the information display for
explanatory or educational purposes.
Research access based on protocol approval and privileges. Access from external
sites include locations such as nursing homes, outreach practice sites, and home-
based care centers.
System performance: Response times for information retrieval/display need to be
measured in sub-second time frames.
Text processing/analysis: Systems will need to be developed which can analyze text
from voice or transcription entry and evaluate content and meaning.
Confidentiality and security maintenance: Robust systems to ensure patient data pro-
tection are required.
Display: Full color, but with provisions to accommodate individuals with color
vision impairment. Document image display to permit reading letters, previous
R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76 69

records, etc. that have been scanned into the computer-based patient record. Ab-
ility to display photos. Minimum display resolution and dimensions such that a dou-
ble medical record sheet can be displayed and read on a single screen. Ability to
scale (zoom in and out) on all images. Diagnostic image display when electronic
versions of these images are available.

Presentation formats:

(4 Help information available to the user quickly at every stage of an applica-

tion. To the greatest degree possible, this information should be specific to
the task or data entry that the user was undertaking at the time help was
sought.
(b) Alternative display formats for medical record data that include: problem-
based, physiologic-systems based, and chronologically based.
(c) Selectable presentations. Form of presentation for various elements select-
able by the user to best lit their needs. Elements or choices in such selection
might include: organization of the history; tabular vs. graphic vs. flow sheet
displays; user selection of warnings/alerts, etc.; color schemes (to accommo-
date color-vision limitations).
(4 Exception lists/alerts. The provision of alerts, exception notations and
prompts determined by an individual user’s requirements. These might
include: exception reporting of abnormal or special findings; simple user-
specified schedules or protocols; message alerts; appointment/call-back
reminders, etc.
(e) Graphic user interface (GUI) desirable, but its presence should not limit the
selection or design of back office support systems which may require only
text-based terminals to operate.

Interaction (selection, command, direction).

(4 Pointing devices, including both pen and linger pointing. In settings where
information is being added to the patient record, a drawing tablet (or equiv-
alent) should be provided to allow the inclusion of sketches as part of the
record. Mice, while they are the most common device in use today have sig-
nificant limitations for use in many of the common settings for a profes-
sional workstation. Track-balls (an alternative to mice) are not generally
well-received by users.
(b) Keyboard interaction available as an option in almost every setting.
(c) Bar-code scanners or wands essential as they permit rapid, positive identifica-
tion of patients and material needed in the provision of care.
(4 Menus vs. command line: Application and workstation design to permit both
interaction by selection from hierarchical menus, and rapid navigation entry
from keyed ‘command lines’ or customized item listings.
(e) Voice recording as an essential means of capturing information at these
workstations.
70 R.A. Greenes et al. / Int. J. Biomed. Comput. 34 (1994) 59-76

Entering/adding textual information: Free-form entry assumes the ability to encode

some of the content of the text to facilitate its organization, retrieval and presen-
tation. Dictation provides for the efficient entry of free-text. Initially this will in-
volve keying by a transcriber. Voice recognition may be an alternative. Keyboard
entry of text should be provided in virtually every circumstance. Pen-based entry
will be needed for sketches that must be part of patient documents.
Entering/adding other information: Provisions must be provided for the capture of
externally (to the institution) generated data about the patient. Provision of docu-
ment scanners near or at the workstation, coupled with the ability to incorporate
facsimile information are minimum requirements.

Other attributes:

(a) Printed output should be convenient to most workstations to permit printing

of items such as prescriptions, summary letters, and health information for
patients.
(b) Sound output capability will be required if the dictation system is embedded
in the workstation.
(c) Rule evaluation capability: The workstation must be capable of quick
response for critical rule sets to support such functions as: managed care
rules, order or data entry validation to permit basic checking prior to sub-
mission of the order to a central order management function, simple pro-
tocols either user-defined or standard, or user-programmed alerts.

Security: Standards to preserve data confidentially and integrity are critical elements
for the successful implementation of the clinical workstation. Provider identitica-
tion will be required to manage .user authorizations and link caregiver identifica-
tion to care events.
Problem list ( ‘master sheet ‘). An organized list of a patient’s significant clinical con-
ditions, treatments, and other notable events. The problem list should be organiz-
ed with multiple views to meet the specific needs of individual caregivers as well
as the general needs of all. Should be able to: extract abnormal or significant re-
sults from other portions of the patient record and place them on the problem list
automatically; and allow care givers to flag information elsewhere in the record
for inclusion on the problem list.

From F.C. Jean et al. [6]:

Ability to help the medical practice: Easy access to different parts of the medical rec-
ord (i.e., quantitative and qualitative information, texts, images, signals) and the
capability to present medical information in multiple formats (e.g., summaries,
tables, charts). Help in the decision-making process (e.g., diagnosis, therapeutic,
prognosis, or supervision suggestions).
Ability to evaluate medicalpractice (e.g., statistical queries on sets of medical records,
evaluation of clinical procedures).
Facilities to help teaching and research (e.g., access to databanks, to libraries of medi-
cal procedures).
R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76 71

Logistic capabilities (e.g., desktop publishing, mailing facilities, personal data man-
agement).
User assistance (e.g., personal customization of the station, on line help or tutorial).
Confidentiality andprotection: Guaranteeing data integrity and security through user
and transaction identifications and authentications.
Data integration: The ability to share data is a key point to integrate components.
Presentation integration: Reduction of the user’s cognitive load when interacting
with individual components, component sets or the system as a whole, by pro-
viding a consistent interaction model. Presentation integrated may be reflected at
three levels in a workstation: the window system, the window manager, and the
look-and-feel guidelines.
Communication integration: Allows the components to interact with no information
loss and semantic mismatch even within a heterogeneous environment.
Control integration: Occurs when components are able to notify other components
of event arrivals, to activate other components under a general control and to
share common functions.

From C. Safran [7]:

Integrated design: The workstation must be patient-centered, the interface must be
uniform, and data acquisition must be addressed at a system level.
Integrated database: An item of data should be entered only once but displayable
many times. The display has to be flexible and rapid.
Help availability: Help must be provided to clinicians for administrative tasks: e.g.,
scheduling, test ordering, referral, and managed care.
Communication support: The workstation should facilitate communication. It should
help compose and manage electronic mail.
Decision support: The workstation should provide decision support.
External knowledge: Access to literature and external databases.
Clinical calculations: Determining drug doses in pediatrics is an example. Labora-
tory data should flow seamlessly into the database, patients’ weights should be
collected routinely, and medications should be entered during prescription
writing.

From J.L. Foy [8]:

1. Access to: (a) Patient records from one or more databases, connected via network,
e.g., pharmacy, laboratory, radiology. It is increasingly recognized that other
modalities (images, waveforms, even sounds) are highly desirable. (b) Reference
information from secondary sources, containing summarized and synthesized
knowledge. May include remote databases such as Medline, Cancerlit, PDQ,
and/or local copies (e.g. on CD-ROM) of the same or other sources such as text-
books. (c) Population data: information derived from aggregates of patient
records.
2. Data presentation: (a) Structured andformatted textual data of many kinds, such
as the sequential narrative of clinicians’ notes, reports from ancillary depart-
ments, patient lists, etc.; (b) Graphs of numeric data; (c) Time-oriented,flowsheets
 R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76

of many different variables both numeric and textual; (d) Specialized displays,
e.g., of acid-base relationships; (e) Waveforms, e.g., of EKG, pulmonary function,
obstetrical monitors; (f) Images, including radiographs, scans, gross and micro-
scopic anatomic and other photographs, and complex image computation such as
three-dimensional rendering, ray tracing, etc.
Computation: Drug dose calculations in clinical contexts (pediatric, oncologic,
hepatic/renal impairment, etc.), IV flow rate calculations, units conversions, and
many other common and specialized cases.
Structured data entry: Orders, notes, reports, problem lists, etc; plans of care,
observations, charting, notes, etc.; ancillary department reports; and so on.
Integrated combinations of the above: For example, checking for drug interactions
is optimally done directly with the physician, during the planning process prior
to order entry, and involves structured data entry (drugs under consideration), ac-
cess to patient data (drugs patient is currently taking), access to reference infor-
mation (drug interaction database), computation (the logic of the interaction
check), and possibly some specialized data presentation.

From J. Kouwenberg (see acknowledgements):

Accessibility: It is possible to communicate with the information system anywhere
in the hospital.
Single access point: All necessary information is available from the same ‘Informa-
tion Access Point’.
Security: All information put in the system is secure according to user defined rules.
Availability and reliability: If vital information is to be stored in the system, it must
be available 7 days/week, 24 h/day, and all data should be correct.
Related and abstracted information: The information system handles relations and
abstractions (e.g. the treatment of a patient also generates information for billing
and for hospital management).
Authorized access: The patient information may in general only be accessed by
authorized persons for an authorized purpose.
Automatic backup of data.

From G.J. Buffone and R.J. Beck [9]:

I. Point of need access: To support physician communications, facilities have to be
provided at the point of need, i.e. virtually anywhere a physician may need to
receive or communicate information about a patient or patients. Communication
facilities should support accesses to: (a) Patient records (regardless of source sys-
tem) for review of existing or new information, and for addition of observations,
plans and communication of orders. (b) Ancillary service systems for review of
data, test status. (c) E-mail for communications with colleagues, nursing and
other hospital, office personnel, and patients. (d) FAX for receipt/transmission of
documents (OCR required on stationary workstation). (e) Voice communication
with colleagues, nursing and other hospital, office personnel, and patients.
R.A. Greeneset al. / Int. J. Biomed. Comput. 34 (1994) 59-76 73

2. Physician workstation should provide utilities for: (a) Image retrieval, presentation,
and annotation; (b) Image transmission; (c) File transfer; (d) Database access and
query (patient records, medical literature, knowledge bases, research records,
etc.).
3. Inter-institutional communication: Treatment outcomes for specific patient popula-
tions, treatment protocols, practice guidelines, research protocols, etc. need to be
distributed among physicians and hospitals prior to official publication of find-
ings both as a part of routine practice and to facilitiate research in clinical
medicine.
4. Patient communication facilties: Support for access to medical knowledge bases
that provide a means for patients to obtain information relevant to their condi-
tion, potential treatments and known outcomes for such treatments. Patients will
also need facilities that support verbal, document and E-mail communication
with community or hospital based physicians for the purpose of describing symp-
toms and receiving advice prior to seeking medical care or reporting changes in
symptoms, adverse drug effects, etc.
5. Patient record sharing: The record generated at a given facility or selected elements
of the record will need to be shared between hospitals, clinics, and physician prac-
tice groups who may be involved in a patient’s care over time. A history of patient
record distribution including dates of distribution, recipient institution and physi-
cian, etc. will need to be maintained and communicated to all parties sharing por-
tions of a lifetime patient record.

9. Appendix B. Three related scenarios for developing functional requirements

(Revised from notes by R. Shannon and D. DeBrota)

Scenario 1. 50-year-old white male patient with recent episode of hemoptysis

presents to primary care MD office. Analysis with respect to primary MD.
Scenario encompasses initial workup, assessment, ordering of initial, X-rays, hos-
pital admission, consultation with radiologist, determination of subsequent tests,
treatment, and discharge to home nursing care.
Scenario 2. Same patient, with respect to radiologist.
Scenario encompasses first encounter with request for examination, examination
process, interpretation, seeking of additional clinical information, differential
diagnosis and workup discussion with primary MD, initiation of subsequent
workup.
Scenario 3. Same patient, with respect to nurse.
Scenario encompasses admission to hospital and provisional diagnosis, develop-
ment of care plan, institution of treatment, modification of treatment as diagnosis
becomes clarified, discharge.

The following is an outline of a portion of the example analysis developed for

Scenario 1 above (the primary care MD perspective):
Assume patient’s condition is not severe or emergent; assume patient identtjication,
14 R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76

registration has been accomplished; retrieve prior records/information from office

records
Note this may require authentication, authorization
Orient serf to patient (retrieve/conceive gestalt’)
Has patient been seen before?
Do I know him?
Greet patient, request chief complaint
Workstation generates differential, prepares initial context model
Obtain detailed history of present illness
Update past history
Assumes review of systems done in past
Physical examination
Highlight pertinent symptoms and signs
Generate or update differential diagnosis, formulate preliminary diagnosis
Discuss impression and preliminary plan with patient
Arrange hospital admission
Authentication
Authorization
Transfer demographic, financial information
Write orders
Diet, medication, nursing, diagnostic studies, consultant orders, establish ratio-
nale/justification for orders, use predetermined order sets when possible
Review/update differential (as new data becomes available)
inform patient and discuss
Additional orders
Information access
Alerts, reminders

10. Appendix C. A glossary of useful definitions

(Revised from contributions by S. Hufnagel)

Architecture Description Language (ADL): A formalism for describing components’

structures and specifying their protocols.
Computer Aided Software Engineering (CASE) Tools: Automate methodologies
using a notation. Ideally, they create an exchangeable data dictionary. Some com-
mercial tools are: CADRE’s Teamwork series, IDE’s Software Through Pictures,
i-Logix’s STATEMATE, Coad’s OOATool and ObjectTool, Rumbaugh’s OM-
Tool, Select’s PC HOOD and PC C++ Designer.
Component: Reusable object which conforms to an interface protocol.
Domain Model: A description (generally in graphical form) providing a structure
into which reusable components can be installed. The components must conform
to an interface protocol.
Domain-Specific Software Architecture (DSSA): A methodology for producing a
specification which enables assembly of software components that are specialized
for a particular domain [3].
Execution Trace: Sequence of events as a scenario is executed within a system.
R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76 75

Formal Methods: Frameworks for describing component behavior in a reuse envi-

ronment. These can range from structured test or program design languages
(PDL) to state transition diagrams to mathematically robust languages such as:
Z, VDM, LOTOS, SCR, Petri-nets, and state charts. The advantage of this ap-
proach is that formal specifications lend themselves to mathematical and sym-
bolic reasoning and automated (re)certification of (re)conIigured systems.
Graphical User Interface (GUI): Tools which provide for the rendering of visual be-
havior and user interface on a hardware/software platform, such as those of
UNIX X and MOTIF, MS-Windows software development kit, Borland Object
Vision, Microsoft Visual BASIC and Visual C++, and Macintosh OS.
Life Cycle Model: Software Analysis and Design Technology (SADT) approach to
describing system requirements that can lead to executable systems. One starts
with re-engineering, or reuse, or rapid prototyping. This feeds into an incremental
development process that eventually results in a rapidly (re)configurable, (re)cer-
tiliable logistic system support environment. Analysis scenarios evolve into an
automated validation test suite. All documentation is generated from the data dic-
tionary. The Scenario-based Engineering Process (SEP) is a concurrent process
model.
Methodologies: The iterating and concurrent construction processes to build and
evolve systems throughout their life cycle. These processes include analysis, de-
sign, implementation integration, and testing.
Notation: The means of expression to communicate a system design.
Object-Oriented Software Construction: An evolving, iterating process of domain
and requirements’ analysis, design, implementation, integration and test. Artific-
ial intelligence (AI) techniques and tools may help to automate this process. Ob-
ject Oriented Data Base Management Systems (OODBMS) encapsulate data and
associated methods into objects. Additionally, the thread of execution migrates
into an OODBMS, contrasting it with relational data bases.
Object-orientedprogramming (OOP): Building of systems from objects rather than
from functions and global data. Common OOP languages are: C++, Objective C,
Eiffel, Smalltalk, and Ada-9x (Object Ada).
Open Systems Architecture: Framework into which can be plugged reusable com-
ponents conforming to the interface.
Reference Architecture: A description of an environment which is comprised of: (i)
domain models, (ii) component descriptions, (iii) interface definitions, and (iv)
compositional languages (including architecture definition language, domain vo-
cabulary, and associated semantic specification language).
Requirements: (a) Functional - focus on what the system does (verbs). (b) Object-
Oriented - focus on the composition of system components. (c) Flow-Oriented
- specifying the thread of execution (tasks or scenarios).
Reuse Library: A data dictionary of formally specified components and their inter-
relations (e.g., state transition diagrams, or Ada or C++ pseudo code, or Z formal
specifications) to instantiate a DSSA. This will likely be an environment built
upon a knowledge base and/or expert system.
Scenario-based Engineering Process (SEP): A DSSA lifecycle methodology which
utilizes: (i) textual description; (ii) expert knowledge acquisition and scenario role
16 R.A. Greenes et al. /ht. J. Biomed. Comput. 34 (1994) 59-76

playing; (iii) ‘clip art’ and/or videos of conceptual animation; (iv) model event
trace and validation; (v) demonstration model animation; and (vi) an executable
validation test suite.
Scenarios: Hierarchically defined traces through a particular system (e.g., ambula-
tory care, rural care, trauma care scenarios).
Simulation: A means to predict or validate the performance or behavior of a system
by modeling its functions.
Specification Language: A means to define component structures, protocols and in-
terfaces, and/or behavior.
Tools: Computer software needed to support tasks including those of system design,
development, testing, verification and validation, and generation.
Verification and Vulidution (V & V): The process of confirming conformance to sys-
tem specifications and meeting customer/user needs, respectively.

11. References

Greenes RA and Shortliffe EH: Medical informatics: an emerging academic discipline and institu-
tional priority. J Am Med Assoc, 263 (1990) 1114-I 120.
Hufnagel S, Harbison K, Silva J and Mettala E: Health care professional workstation: software sys-
tem construction using DSSA scenario-based engineering process. Inr J Biomed Compur, 34 (I 994)
375-386.
Nowlan WA: Clinical workstations: identifying clinical requirements and understanding clinical in-
formation. Inr J Biomed Comput, 34 (1994) 85-94.
Nobel JJ: The health care professional’s workstation: a call to action. Int J Biomed Comput, 34
(1994) 21-28.
Carpenter PC: The electronic medical record: perspective from Mayo Clinic. Int J Biomed Comput,
34 (1994) 159-171.
Jean FC, Lavril M, Lemaitre D, Sauquet D and Degoulet P: A software engineering approach for
medical workstation development. Inr J Biomed Compuf, 34 (1994) 249-260.
Safran C: Defining clinical ‘workstation’. Inr J Biomed Compuf, 34 (1994) 261-265.
Foy JL: Integrating non-proprietary workstations into proprietary systems. Int J Biomed Comput,
34 (1994) 277-283.
Buffone GJ and Beck JR: Facilitation of health care delivery through enhanced communications.
Int J Biomed Comput. 34 (1994) 349-355.