A methodology for incorporating web technologies into a computer-based patient record, with...

A methodology for incorporating web technologies into acomputer-based patient record, with contributions from

cognitive science

Charles Webster

JMJ Technologies, 1335 Canton Road, Suite C, Marietta, GA 30066, USA

Abstract

Cognitive science is a rich source of insight for creative use of new Web technologies by medical informatics workers.

I outline a project to Web-enable an existing computer-based patient record (CPR) in the context of ideas from

philosophy, linguistics, artificial intelligence, and cognitive psychology. Web prototypes play an important role (a)

because Web technology lends itself to rapid prototype development, and (b) because prototypes help team members

bridge among disparate medical, computing, and business ontologies. Six Web-enabled CPR prototypes were created

and ranked. User scenarios were generated using a user communication matrix. Resulting prototypes were compared

according to the degree to which they satisfied medical, computing, and business constraints. In a different

organization, or at different time, candidate prototypes and their ranking might have been different. However,

prototype generation and comparison are fundamentally influenced by factors usefully understood in a cognitive

science framework.

# 2002 Elsevier Science Ireland Ltd. All rights reserved.

Keywords: Computer-based patient record; Electronic medical record; Web; Internet; Cognitive science

1. Introduction

World Wide Web and Internet technologies

are having an important impact on health care

and medical informatics [1], at least partly

because these technologies lend themselves to

rapid prototyping [2]. A plethora of plat-

forms, development tools, tutorials, and ex-

ample code can be downloaded and

demonstrated. At the same time, the kinds of

people who are taking advantage of these

technologies are changing, from pure technol-

ogists to people with interdisciplinary back-

grounds, as well as members of

interdisciplinary teams. Cognitive science is

an excellent source of ideas for understanding

design and implementation issues arising out

of this dynamic mixture of technology and

medicine [3,4].Some problems encountered when Web-

enabling an existing computer-based patientE-mail address: [email protected] (C. Webster).

International Journal of Medical Informatics 68 (2002) 39�/47

www.elsevier.com/locate/ijmedinf

1386-5056/02/$ - see front matter # 2002 Elsevier Science Ireland Ltd. All rights reserved.

PII: S 1 3 8 6 - 5 0 5 6 ( 0 2 ) 0 0 0 6 2 - X

mailto:[email protected]

record (CPR) are intrinsic to the nature ofWeb technology, but others are inherent in theproperties of medical informatics in the realworld, where technologists, clinicians, andmanagers must understand each other wellenough to work successfully together. Thispaper reports on a project to Web-enable anexisting CPR, while reflecting on ideas fromcognitive science that help understand reasonsfor success or failure of such projects.

2. Materials: concepts from cognitive science

The following topics are drawn from phi-losophy, linguistics, artificial intelligence, andcognitive psychology, all areas of knowledgethat contribute in important ways to cognitivescience.

2.1. Philosophy and incommensurability

A fundamental problem encountered inmedical informatics is that of incommensur-able domain ontologies. The sets of concepts,and relationships among them, characterizingmedicine, computing, and business only par-tially overlap (Fig. 1) [5]. Concepts drawnfrom each ontology can be incommensurable;

they lack necessary common qualities onwhich to direct comparisons.

For example, basic ideas like ‘cell’, ‘profit’,and ‘byte’ come from such different frame-works that they are difficult to compare andcoherently integrate. As a consequence, it isdifficult to think, or to teach students tothink, like a clinician, computer scientist,and manager at the same time.

2.2. Linguistics and pidgin dialects

People from different disciplines are oftendescribed as speaking different languages.Within a discipline, language shares a com-mon vocabulary and is sometimes referred toas a ‘sublanguage’ [6]. Communication be-tween speakers from different disciplines is akind of pidgin [4]. A pidgin is a mixture or twoor more languages, with a simplified grammarand vocabulary, used for trade betweenspeakers of different languages. Speakerstend to restrict themselves to simple conceptsfrom their own ontology (so as to avoid losingtheir audience) and simple concepts fromforeign ontologies (due to relative unfamiliar-ity).

A pidgin has no native speakers, but overtime a pidgin can evolve into a creole, with arich vocabulary, complex rules*/and nativespeakers. Speakers trained in medical infor-matics are evolving a language closer to acreole than a pidgin [4]. However, even asmedical informatics solidifies its position as aseparate scientific and engineering discipline,for the foreseeable future many medical soft-ware projects in the real world will requirecommunication among ‘non-native’ medicalinformatics speakers.

2.3. AI and the shared meaning problem

Distributed artificial intelligence is thestudy and creation of systems in which twoFig. 1. Disparate ontologies.

C. Webster / International Journal of Medical Informatics 68 (2002) 39�/4740

or more autonomous agents interact intelli-gently. The shared meaning problem ariseswhen cooperating intelligent agents do notshare a common ontology, and, therefore,cannot communicate. Solving the sharedmeaning problem requires the ability to learnnew symbols and associated meanings, whichin turn requires a shared physical environmentupon which to ‘ground’ shared symbols [7].

Solving the shared meaning problem isreminiscent of the interaction between a fieldlinguist and an informant speaking a pre-viously undocumented language. Linguist andinformant point out objects and repeat theirnames (nouns), progressing to activities(verbs), and more complex constructions.Likewise, prototypes of Web-enabled CPRsprovide a shared environment in which agents(physicians, programmers, and managers) canlearn shared concepts, rules for combiningthem, and practical communication strategies.

2.4. Psychology of creativity

Regardless of tool, notation, procedure orcriteria for success, development of medicalsoftware is accomplished through sharedunderstanding, communication, and creativ-ity. A classic description of the creativeprocess is Wallas [8,9]: (1) preparation, learnabout a problem and possible elements of asolution; (2) incubation, period during whichassociations among elements form; (3) illumi-nation, a useful constellation of associatedelements emerges; (4) verification, a solution isimplemented to see if it really works. Recentcomputational accounts emphasize ap-proaches inspired by Darwinian natural selec-tion [9].

Restating these stages of the creative pro-cess in the context of Web-enabling a CPR,they are (1) preparation, investigate a numberof Web technologies; (2) incubation, associatecombinations of Web technologies; (3) illumi-

nation, select most successful combination(s);(4) verification, build the prototypes. Notethat these stages are accomplished by acombination of individual and group activity,consistent with a distributed cognitive ap-proach [10], another important area of cogni-tive science research.

The cognitive origins of technological crea-tivity (such as is discussed in Dasgupta [11])are beyond the scope of this article. Suffice itto say that in the face of new technology anddisparate domain ontologies, developing soft-ware is fundamentally a creative psychologicalprocess.

3. Methods: imagining Web-enabledprototypes

3.1. Web-enabling an existing client�/serverCPR

The existing clinical charting and workflowmanagement CPR (�/160 sites, �/2000 users)includes (for example) a patient trackingscreen; a vitals screen for nurses’ examina-tions; an encounter-screen for physicians’orders, progress notes, histories, and otherrecords; allergy and immunization screens;dynamic short lists customized to the prefer-ences of each practice, and in some cases toeach physician in the practice; alerts; prescrip-tion ordering screens, as well as many otherorder entry and data summary screens. In-formation, beginning with patient check-in,flows from screen to screen in an accumulativeand value-added process, until patient check-out. This information*/on all current andpast encounters*/is available in real time tomultiple users.

Discussion of how to take advantage of theWeb technologies proceeded through a num-ber of phases: debate about Web-based versusWeb-enabled approaches, discussion of front-

C. Webster / International Journal of Medical Informatics 68 (2002) 39�/47 41

end (thin-client oriented) versus back-end

(application-integration oriented) software

development, creation of a user communica-

tion matrix, generation of user scenarios, and

development and ranking of prototypes.I’ll define a Web-based CPR as one that is

predominately constructed out of Web-related

technologies, whereas a Web-enabled CPR

contains at least one Web-based subsystem.

It is presumably easier to Web-enable an

existing system than it is to completely

recreate a Web-based system. However, the

question becomes: which subsystem to Web-

enable, and how? Since Web technologies tend

to involve some kind of communication, a

communication matrix was created containing

hypothetical user roles most relevant to our

CPR (Table 1).Exhaustively visiting each potential interac-

tion, those external to our market niche were

ruled out. Relative to the remaining interac-

tions, each was explored thoroughly with

respect to implications for the existing CPR.

This was further narrowed to five Web-

enablement scenarios: projecting the user

interface over Web (Fig. 2), Web-based pa-

tient�/physician communication (Fig. 3), wire-

less anywhere-anytime access to patient data

(Fig. 4), exchange of physician CPR customi-

zations (Fig. 5), and embedded Web services

(Fig. 6).One or more prototypes for each of these

five scenarios were built in order to learn

about the technology (a computing goal), to

assess clinical demand or need (a medical

goal), and to estimate resources necessary to

Table 1

Web-enabled user communication matrix

Communication from\to Physician1 Physician2 Patient Consultant Service provider

Physician1 � � � � �Physician2 � � � �Patient � �Consultant � �Service provider �

Physician1 and Physician2 are current CPR users at different CPR location sites. Consultant is an external consulting physician who

is not a current CPR user.

Fig. 2. ASP-based CPR.

Fig. 3. Patient portal to CPR.

Fig. 4. Wireless access to CPR.


deploy that version of a Web-enabled CPR (abusiness goal).

4. Results: comparing Web-enabled prototypes

Prototypes were implemented for all but thefirst of the following: Thin-client HTML, JAVA,and user interface emulation, all of which areexamples of application service provider(ASP) approaches; patient portal; wirelessaccess; XML-based exchange of user customi-zations, and an embedded Web service.

4.1. Thin client: HTML

An obvious way to Web-enable a CPR is toattempt to Web-enable every aspect of theuser interface, to create a purely Web-basedCPR user interface.

1) No (Computing): HTML is a mature,cross-platform technology, but has limited

GUI functionality, and, without executionon the client, user experience is sharplydiminished compared with the client�/

server CPR. It is a great way to retrieveand review data, but an awkwardly slowway to enter data.

2) No (Medical): Clinical users do not (anddid not) find that the interface is richenough and responsive enough to routi-nely enter clinical encounter data.

3) No (Business): The cost of implementing afull featured Web-based interface to aCPR (let alone a full featured Web-basedCPR) is relatively high. This is due to thecomplexities of designing, implementing,and maintaining the code necessary fordynamic generation of HTML pages foranything approaching a comprehensiveCPR (which would necessarily includedata input as well as retrieval).

4.2. Thin client: JAVA

JAVA presents an attractive version of a rich

graphical user interface (GUI) and quick user

response, running in a browser or on a desk-

top (but initially delivered and installed via a

browser).

1) No (Computing): While client-side JAVA

provides a rich interface and quick re-sponse to user input, it is also less maturethan HTML for cross-platform distributionof a GUI.

2) Yes (Medical): Demonstrations of datainput capabilities appeared to convinceobservers of an adequately rich and re-sponsive set of user interface features.

3) No (Business): The lack of cross-platformdistribution capability along with the needto essentially duplicate existing clientapplication user interface screens sug-gested that effort to develop and maintain

Fig. 5. XML-based knowledge transfer.

Fig. 6. Embedded Web services.


would likely be greater than what we felt

was practical.

4.3. Patient portal

A patient portal gives patients access to

CPR data and facilitates communication

between physician and patient.

1) Yes (Computing): Building a patient por-

tal is technically feasible. A simple de-

monstration prototype revealed that our

application is particularly compatible with

such a companion application, due to its

workflow emphasis and component-or-

iented design.2) No (Medical): While patients are positive

about follow-up email communication

with their physician, physicians are justly

concerned with the possibility of email

going astray. (While a partial solution is

to email links to sensitive data and

authentic the user when they follow a

link, the issue of unauthorized access

remains of concern.)3) No (Business): From the point of view of

management of a company selling a CPR,

a patient portal really represents a sepa-

rate venture. The core competencies to

create such a successful enterprise are

considerably different, particularly when

it comes to infrastructure and marketing.

Instead, discussion has focused on devel-

oping a object oriented or XML-based API

for other ventures (including patient por-

tals) to leverage our application.

4.4. Wireless PDA

A Palm VII wireless application was devel-

oped that gave abridged access to CPR data.

1) Yes (Computing): Wireless PDA (perso-nal digital assistant) access to CPR isrelatively easy to provide.

2) No (Medical): Demonstrations of wirelessaccess garnered positive reactions, butsimilar to the patient portal, reactionswere mixed. Our interpretation was thatonce potential users feel they have data tobe accessed, they will be more interested ina variety of ways to access the data.

3) No (Business): Wide area wireless accesswas not perceived as a must have feature,in either the sense that potential buyerswould buy our CPR in order to gainwireless access to its data, or in the sensethat they would not buy it unless itprovided such access.

4.5. Embedded Web services

Web services are URL-addressable re-sources that can be accessed programmati-cally by a client using standard protocols suchas HTTP and XML. The kinds of Webservices that CPRs will likely use include laband prescription services. In order to proto-type the embedding of services within ourCPR, a Web-based patient questionnaireservice was created.

1) Yes (Computing): We chose to implementa Web-based patient questionnaire serviceusing a combination of Simple ObjectAccess Protocol calls and Enterprise JavaBeans running on a Web applicationserver. It worked well.

2) Yes (Medical): Web services, themselves,are invisible to the user, but they makepossible certain content and behaviors.Potential and current users seemed veryinterested in the particular functionalitywe prototyped, namely a patient ques-tionnaire integrated into the CPR (as ameans, perhaps, to reduce the time spent


per patient in entering subjective historydata).

3) No (Business): There was an alternativemeans to provide the patient question-naire functionality within the CPR, usinga patient questionnaire software compo-nent. Using a Web service-based approachpresupposes Web service server infrastruc-ture. Either we need to provide it or relyon a Web service partner (who presum-ably can amortize the cost of developmentand ongoing maintenance over provisionof the service to multiple customers). TheWeb service provider did not yet exist.

4.6. XML knowledge transfer

Using editors integrated into the CPR,physicians can customize their local CPR, aform of knowledge acquisition. Intending toharness this creativity, a means to export andimport customizations using an XML-basedfile format was developed.

1) Yes (Computing): Certainly, XML-relatedtechnologies exist to export and importthe contents of relational database tables.A simple example was implemented. Nu-merous XML-based translation engineshave since become available for transfer-ring content from database to databaseusing XML.

2) Yes (Medical): At the time, there was agreat need to move medical contentamong the various specialty databases.(For example, both a pediatrician and afamily practice physician would likelywant access to a detailed asthma ques-tionnaire.)

3) Yes (Business): At the time, we main-tained separate databases for each speci-alty. In the mean time, we have moved toa single database that supports multiplespecialties. Because it is a single database,

the need to move customized contentbetween databases has been reduced.

4.7. Thin client: GUI emulation

GUI emulation (also called terminal emula-tion) is the general approach, reminiscent ofdumb terminals accessing mainframes, ofpresenting to the user an image of an applica-tion that is actually executing on a serverelsewhere (possibly over a public wide areanetwork such as the Internet, but usually overa high bandwidth virtual private networkusing Internet technology).

1) Yes (Computing): Given enough resourceson the server, GUI emulation works well.

2) Yes (Medical): Users experience the samerich graphical interface that they experi-ence on the client�/server application.

3) Yes (Business): The resources required onthe server for large-scale deployment canbe formidable compared with alternativethin-client approaches. Nonetheless, ne-cessary resources and our typical user/sitedeployment size matched nicely. Given thealmost ‘drop in’ nature of a terminalservices approach, the cost of develop-ment is much less than the alternative, andtherefore, presents an attractive businesscase.

Each prototype was compared according tothe degree it satisfied each of the computing,medical, and business constraints. Combined,these constraints are the selection criteriaapplied to determine which prototypes ‘sur-vived.’ As can be seen in Table 2, XML-basedknowledge transfer and GUI emulation occu-pied the leader positions. Ultimately, proto-type GUI emulation has been very successful,while, as already noted, the requirement formovement of specialty content has diminishedsomewhat.


5. Discussion

The prototypes were conceived, implemen-ted, and compared*/and this paper was

initially drafted*/during the height of theso-called Internet economic bubble. ManyCPR companies were aggressively investigat-

ing the new Internet technologies. Thus, theInternet boom was a time of energetic experi-mentation from which lessons may be learned.

Within a relatively short amount of time weimplemented a half a dozen prototypes that

involved extending an existing CPR to includesubsets of these new Internet technologies.The effect of these prototypes on our shared

mental models and discussions of strategicdirections was substantial.

It should be made clear; we did not adopt a

formal requirements analysis strategy to de-cide which strategic direction held the mostpromise. To understand the new technologies,

we implemented whatever seemed to be themost promising. By considering a variety of

strategic directions, embodied in the proto-types, we developed an appreciation of thetechnological/opportunity landscape around

us, in terms of our and competitors’ positionsin that landscape. Indeed, sometimes weinvestigated an area and built a prototype in

response to reports that a competitor waspressing forward in this specific direction,only to come to the conclusion that not only

was it not practical for us, but that is probably

was a mistake for them. After several itera-tions of this cycle, this author saw an oppor-

tunity to try to understand the variousrelevant criteria implicitly applied to proto-type evaluation in terms of the medical,

management, and technology domains thatseemed to categorize the stakeholder view-

points.Roughly, software engineering has pro-

ceeded from a waterfall model (requirements,

design, implementation, testing, maintenance,in that order), to a prototyping and iterativedevelopment approach, to the more recent use

case and scenario-based usability engineeringapproaches [12]. (A scenario is a story aboutpeople engaged in an activity.) Given enough

disparity among stakeholder domains (such asamong medicine, management, and technol-

ogy) scenario construction can be hamperedby lack of shared concepts and terminology.Prototypes served the purpose of grounding

scenario discussion.The prototypes were ‘chauffeured’ proto-

types (albeit runnable, not the paper-and-

pencil simulated variety); representative usersdid not interact directly with an application.The prototypes implemented core functions

but had little error detection (and no docu-mentation). The prototypes allowed the de-

signer to walk through a runnable applicationwhile representative users looked on.

In another organization, with different

users, resources, and technologies, different

Table 2

Comparison of Web-enabled prototypes (see text for explanation)

Prototype/ontology 1. Meets computing constraint 2. Meets medical constraint 3. Meets business constraint

Thin client: HTML No No No

Thin client: JAVA No Yes No

Patient portal Yes No No

Wireless PDA Yes No No

Embedded Web services Yes Yes No

XML knowledge transfer Yes Yes Yes

Thin client: GUI emulation Yes Yes Yes


prototypes might have been explored orranked differently. Over time, all of thesescenarios and approaches may eventually bepursued. Prototypes facilitated learning, com-munication, and consensus. Imagining, build-ing, and comparing multiple prototypes*/

using them to ground common experienceshared by medical informatics workers drawnfrom complementary, but disparate dis-ciplines*/is a promising approach to creatingshared systems of concepts about how toWeb-enable a CPR.

The purpose of this paper is not to proposea new cognitive science theory, or medicalsoftware methodology, but rather to reinforcethe thesis presented by Patel and Kaufman[3,4], that cognitive science is a rich source ofideas for constructing frameworks useful inunderstanding design and implementationissues in medical informatics. Consistentwith this purpose and thesis is the result of arecent Delphi study of health informaticsexperts, which emphasized the need for re-search into psychological and social issues[13]. The particular framework offered hereemphasizes the importance of overcomingdisparities between domain ontologies andstrategies for creating shared meaning amongprofessionals based in different disciplines.

Acknowledgements

Thanks go to Mark Copenhaver and theemployees of JMJ Technologies for theirvision, energy, and curiosity.

References

[1] J. Briggs, G. Early, Internet developments and their

significance for healthcare, Medical Informatics and The

Internet in Medicine 24 (3) (1999) 149�/164.

[2] M. Vissers, A. Hasman, Building a flexible protocol

information system with ‘ready for use’ web-technology,

International Journal of Medical Informatics 53 (1999)

163�/174.

[3] V. Patel, D. Kaufman, Science and practice: a case for

medical informatics as a local science of design, Journal of

the American Medical Informatics Association 5 (6) (1998)

489�/492.

[4] V. Patel, D. Kaufman, Medical informatics and the science

of cognition, Journal of the American Medical Informatics

Association 5 (6) (1998) 493�/502.

[5] C. Webster, S. McLindon, K. Begler, Why Johnny can’t

reengineer health care processes with information technol-

ogy, in: R.A. Greenes, H.E. Peterson, D. Protti (Eds.),

Medinfo, vol. 8 Pt 2, 1995, pp. 1283�/1287.

[6] R. Kittredge, J. Lehrberger (Eds.), Sublanguage: Studies of

Language in Restricted Semantic Domains, Walter de

Gruyter, Berlin, 1982.

[7] S. Sen, G. Weiss, Learning in multiagent systems, in: G.

Weiss (Ed.), Multiagent Systems: a Modern Approach to

Distributed Artificial Intelligence, MIT Press, Cambridge,

MA, 1999, pp. 259�/298.

[8] G. Wallas, The Art of Thought, Harcourt, Brace & World,

New York, 1926.

[9] C. Martindale, Creativity and connectionism, in: S.M.

Smith, T.B. Ward, R.A. Finke (Eds.), The Creative

Cognition Approach, MIT Press, Cambridge, MA, 1995,

pp. 249�/268.

[10] G. Saloman (Ed.), Distributed Cognition: Psychological

and Educational Considerations, Cambridge University

Press, Cambridge, UK, 1993.

[11] S. Dasgupta, Technology and Creativity, Oxford Univer-

sity Press, Oxford, 1996.

[12] M. Rosson, J. Carroll, Usability Engineering: Scenario-

Based Development of Human�/Computer Interaction,

Morgan Kaufmann Publishers, San Francisco, 2002.

[13] J. Brender, C. Nohr, P. McNair, Research needs and

priorities in health informatics, International Journal of

Medical Informatics 58�/59 (2000) 257�/289.


A methodology for incorporating web technologies into a computer-based patient record, with...

Documents

Transcript of A methodology for incorporating web technologies into a computer-based patient record, with...