i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 8 ( 2 0 0 9 ) 386–390

journa l homepage: www. int l .e lsev ierhea l th .com/ journa ls / i jmi

The realities of implementation of Clinical Context ObjectWorkgroup (CCOW) standards for integration of vendordisparate clinical software in a large medical center

Robert G. Bergera,∗, John Babab

a University of North Carolina Health System, 321 Meadowmont Village Circle, Chapel Hill, NC 27517, United Statesb University of North Carolina Health System, Chapel Hill, NC 27517, United States

a r t i c l e i n f o

Article history:

Received 9 August 2007

Received in revised form

4 December 2008

Accepted 8 December 2008

a b s t r a c t

CCOW standards have been touted to currently be the best way to integrate disparate clinical

applications by passing user identification and passwords as well as patient context between

these applications at the desktop. However, nothing has been published in academic jour-

nals on the actual realities of implementation of CCOW. In this report, we describe the

implementation of CCOW for our three main clinical applications and compare this with the

simultaneous development and implementation of a portal session manager for the same

purpose. We found the portal session manager much easier to develop and implement than

CCOW. The resulting functionality was almost equivalent as judged by our clinical end users

Keywords:

CCOW

EMR

Integration

CPOE

who compared both solutions. We now have the portal session manager functional across

the institution and have stopped any further work on CCOW.

© 2008 Elsevier Ireland Ltd. All rights reserved.

last 4 years with all orders (except chemotherapy) required

Portal

1. Introduction

Over the last two decades UNC Health Care System hasdeveloped and internally programmed its own EMR built onWebsphere and DB2 [1]. We did this because there is noapplication vendor capable of tying all EMR inpatient and out-patient functionality to a single application. We named theapplication WebCIS. This EMR is used by all care providers inboth the inpatient and outpatient settings. There are approx-imately 6000 unique users who query 70,000 unique patientrecords a day, with over 2 million daily transactions withinthese records. In the outpatient areas we currently use no

paper charts as all clinical information is stored electronically.The EMR contains all relevant ancillary reports, procedures,and laboratories in addition to coded problems lists, coded

∗ Corresponding author. Tel.: +1 9199664205; fax: +1 9199662110.E-mail address: rberger@unch.unc.edu (R.G. Berger).

1386-5056/$ – see front matter © 2008 Elsevier Ireland Ltd. All rights resdoi:10.1016/j.ijmedinf.2008.12.002

medications with electronic prescribing direct to pharmacies,coded Health Care Maintenance prompts, PACS images (witha direct interface to our commercial PACS system within theapplication) and many other features that adhere to the Insti-tute of Medicine’s standards for an EMR [2,3]. Direct entry ofclinical care notes (History and Physicals, Clinic Notes, Dis-charge Summaries, etc.) are done by our physicians with adeclining percentage of physicians (including post-graduatetrainees) still using dictation/transcription for these notes.

On the inpatient units we have been using a commercialproduct for Computerized Provider Order Entry (CPOE) for the

to be entered electronically [4]. Recently, we have continuedour attempts to become paperless on our inpatient side ofcare by installing a commercial product providing for nurs-

erved.

a l i n

ima(ditbdOW

tmtldavfcvacaiv

wsvpCiTCnGctTtiwd

2

TaPiardovit

i n t e r n a t i o n a l j o u r n a l o f m e d i c

ng documentation including interfaces from ICU and otheronitoring devices (Echart). As mentioned, we already havedirect interface to our PACS system from our main EMR

WebCIS) that displays images. Our pharmacy system is a stan-alone application that is not required by clinicians to be

nterfaced with any other application; the electronic Medica-ion Administration Record (MAR) has been purchased and iseing installed as a part of the nursing application with theata to populate the MAR originating from the CPOE system.ur other ancillary systems already feed their data directly toebCIS.As a result of the clinical needs and the existing architec-

ure described above, we required integration only of our threeain applications, WebCIS, CPOE, and our nursing applica-

ion (Echart). These applications formerly were individuallyaunched from icons on a PC’s, rolling laptops, and otherevices found throughout our environment. Multiple loginsnd passwords were required and different patients could beiewed among the applications thus presenting the possibilityor wrong data to be placed or interpreted on a given patient ifaregivers were not attentive to which patient was currentlyiewed in each application. This situation made it complex forcaregiver to remember numerous sign-ons to multiple appli-ations by remembering the current user identification (UID)nd subsequent passwords for all the applications, and mak-ng sure that the same patient context was in all applicationsiewed.

To correct this problem we developed a desktop view thatas adherent to Clinical Context Object Workgroup (CCOW)

tandards and simultaneously developed another desktopiew that used a commercial Global Session Manager (GSM)ortal. Though a Google search found multiple descriptions ofCOW [5], a MEDLINE search of all academic journals resulted

n no peer reviewed articles at all on CCOW implementation.hus, this is the first report of the results of implementingCOW standards. After testing and live usage of both tech-ologies by clinicians, we settled on using the GSM (Siemenslobal Session Manager) portal to allow for single sign-on to alllinical applications, and passing of patient context to each,hus eliminating the patient safety issues described above.his report describes the technology we used for both solu-

ions, the technical pros and cons of each, the differencesn operational functionality between the two solutions, and

hy we choose the GSM portal over the CCOW standardizedesktop.

. Background of CCOW and GSM

he current standard that the applications vendors havedopted is CCOW. CCOW standards pass both the UID andatient Context, thus the caregiver has the ability to click ancon the desktop and is able to be logged into the applicationnd to be taken right to the current patient that was in the cur-ent view in another application on the desktop. We started toevelop a plan to make our clinical applications talk to each

ther via the CCOW standards. The HL7 CCOW Standard isendor independent and allows clinical applications to sharenformation at the point of care. Using a technique called “con-ext management”, CCOW provides the clinician with a unified

f o r m a t i c s 7 8 ( 2 0 0 9 ) 386–390 387

view on the information held in separate and disparate health-care applications referring to the same patient, encounter oruser. This means that when a clinician signs onto one applica-tion within the group of disparate applications tied together bythe CCOW environment, that same sign-on is simultaneouslyexecuted on all other applications within the group. Simi-larly, when the clinician selects a patient, the same patient isselected in all the applications. CCOW then builds a combinedview of the patient on one screen. CCOW works for both client-server and web-based applications [5]. The acronym CCOWstands for “Clinical Context Object Workgroup”, a reference tothe standards committee within the HL7 group that developedthe standard.

GSM allows application developers, through sound designdecisions, to implement an integrated workflow between aparent and child application using the Siemens Global Ses-sion Manager to maintain session context information. TheGSM supports numerous configurations and process flows.

3. Methods

The first issue was to make sure that all the applications thatwere to work with CCOW standards were setup in that man-ner. This is where we had to work with and totally understandthe programming in each application. The second issue wasto partner with a vendor that could pass the CCOW standardsto all the applications. Because our disparate applications haddifferent UID and passwords a third issue was to eliminatethese multiple UID and passwords so we had to partner witha Single Sign-On (SSO) vendor. We might have chosen to builda crosswalk UID and password table within the CCOW appli-cation, but decided that because we have other secondaryclinical applications that are not CCOW compliant it was morefeasible to use SSO. Once we decided on a CCOW applica-tion and SSO vendor we then had to make sure that theseapplications worked together. One additional issue we hadto overcome was that the EMR (WebCIS) that we developeddid not meet the CCOW standards. To this end we workedwith the CCOW application vendor to write special code thatcould intercept where a user was within the EMR applicationso that we could pass patient context information to the otherapplications.

CCOW standards state that the CCOW server has to be ableto authorize each application wanting to participate. We there-fore had to build a server to manage the CCOW applicationand these authorizations. The CCOW application requires thata fat client (running process) be loaded onto each worksta-tion (Over 6000 workstations if we went to full production).We also had to load a custom program because of the issuethat our EMR was not CCOW compliant. The SSO productalso needed a fat client on each workstation in addition toprogrammatic changes to our Active Directory product. Aftergetting the CCOW and SSO servers up, we spent about a yearto get CCOW and SSO up and running with our three mainclinical applications (our EMR, a vendor’s CPOE and a vendor’s

Nurse Documentation system). Though the vendor applica-tions were “certified” as being CCOW compliant, they were not,and we wrote custom code within those applications to allowfor true CCOW interoperability.

i c a l

388 i n t e r n a t i o n a l j o u r n a l o f m e d

We presented the working model to our testing physiciansthat consisted of 3 electronic medical record “champions”(a neurosurgeon, a hematologist and a rheumatologist), wholoved the concept of single sign-on and integration of patientcontext between applications. They tested the CCOW enableddesktop (as well as later testing the GSM enabled desktopdescribed below) by logging into our main EMR (WebCIS) andmoving back and forth between this application, and ourvendor supplied CPOE and nursing applications. Within eachapplication, patients were changed and observations on theresultant change to the same patient in the other applicationswere assessed. Response time was subjectively evaluated asexcellent, good or poor. They found excellent response timesin loading each disparate application through both CCOW andGSM as well as accurate and rapid changing of patient contextwithin each application once a new patient was selected.

However we then found that we had more dilemmasto overcome. The most complex issue was that within ourenvironment we have multiple devices for caregivers to use.These are open areas where any caregiver can log onto anapplication and use it without having to log onto the actualworkstation. We use a generic sign-on ID through a stan-dard Windows©“Graphical Identification and Authentication”(GINA) and once logged on to the workstation and the care-giver needs then to only log onto the application. This scenariowould not work because in order for SSO to work the work-station would need to be logged in as the individual person.Also, as part of this, each caregiver would need to have adomain account to authenticate to network. We did not dothis because this would have required an overwhelming oper-ational issue in distributing new logins to the entire institutionand also would have forced our users to remember an addi-tional login/password, which would have been defeated oneof the main goals of CCOW, i.e. to decrease the number oflogin/passwords required in our clinical environment. We alsoneeded to develop a special “GINA” in lieu of the standard Win-dows©“GINA” because of the multiple users that sign on andoff of the same kiosk machines. Since our environment is allthin clients whose “locked down” desktop is controlled by amirrored server, we only have to make changes to that serverto change the desktops across the institution. For physiciansand other care givers who have their own “open” machines intheir offices, they need only to point their browsers to the urlthat opens our main EMR (WebCIS) or if they so choose, cango directly to the urls via browser to the other two main clin-ical applications, i.e. CPOE and nursing. Though we have thecapability of pushing required client code to each lockdownworkstation, because of the client machine configurationsrequired by the CCOW and single sign-on thick client pieces,we were very concerned that we would have to physically“touch each of our 3000 “lock down” computers. Furthermore,we do not have the capability to push code to the “open”machines described above that exist in faculty offices andmany other areas within the institution.

We then went back and looked at two of our vendor’s appli-cations and how they communicated with each other. Our

CPOE and Nursing documentation systems are from the samevendor and they use their proprietary code to make the differ-ent applications talk to each other. They use Java to write theprocedures to make the calls to each application. They call

i n f o r m a t i c s 7 8 ( 2 0 0 9 ) 386–390

this light weight application Global Session Manager. Thereis no fat client to load on any workstation. It comes with atool kit” that contains sample code to use to expand the com-munication concept to other applications not by the samevendor. The concept behind GSM is to pass both UID andPatient Content to another application, the very same conceptbehind CCOW. The difference is that with CCOW there is noParent/Child relationship. In the CCOW environment you canchange patients in any application and the other applicationsfollow. In a GSM environment there is a Parent application thatcontrols changing of patient context. The other difference isthat where CCOW requires a fat client on the workstation, GSMis all coded on the application thus not needing a fat client.

One major issue was deciding the Parent–Child relation-ship. In our scenario we already had a “portal”, our EMR whereall the caregivers go to get information on patients. Our taskwas to connect CPOE and Nursing documentation to this. WithGSM, the child applications cannot allow a way to changepatients. A new patient choice must occur in the parent appli-cation. To do this we had to rewrite code to hide or remove anyarea where you can change patients. Our vendor had alreadyenabled that capability within their applications so it was nothard for us to decide that our EMR was to be the parent portal.

Our first step was to get the two vendor applications totalk to each other via GSM. Within an hour we had it work-ing. We could log into our CPOE system and with a hyperlinkon the same browser we could launch a new window and beautomatically logged in our nursing documentation systemand be taken right to the current patient. That was the easypart because the two applications were GSM enabled. Next weworked on our EMR, now to be considered as our parent portal.This was more challenging because this was not GSM enabled,but was not so complicated because we were going to use thisapplication as our Parent. With some assistance we were ableto make a Java call to both the CPOE and Nursing Documenta-tion system and pass both the UID and patient context. It tookabout a week of development and testing to allow it to go intoproduction

We now have a single browser that launches through ourEMR to our CPOE and Nursing system with a single logon andthe ability to go straight to the same patient which was ouroriginal goal.

4. Results

The technical issues between CCOW (combined with SSO) andthe vendor based GSM discussed above made for major differ-ences in infrastructure but minor differences in functionality.These differences are outlined in Table 1.

As Table 1 illustrates, the advantage of CCOW is that anyCCOW “compliant” application can be launched and the useris automatically logged in (when deployed with a SSO appli-cation) and patient context is passed. There is no “parent”application as there is in GSM portal that the other applica-tions are launched from. This capability makes CCOW more

versatile than GSM as the user may begin with any application,chose a patient, and any other CCOW application opened willmove immediately to the same patient. This comes at a costof time of having the user logon to the domain before opening

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n

Tabl

e1

–D

iffe

ren

ces

betw

een

CC

OW

/SS

Oan

dG

SM

.

Fun

ctio

nG

SMC

CO

W/S

SO

Ap

pli

cati

on“p

aren

t”fr

omw

hic

hot

her

app

lica

tion

sla

un

ched

wit

hp

assi

ng

ofu

ser

cred

enti

als

and

pat

ien

tco

nte

xt

EMR

Non

e,an

yap

pli

cati

onca

nbe

open

edan

dw

illp

ass

use

rID

and

pat

ien

tco

nte

xtau

tom

atic

ally

Init

ialD

omai

nN

etw

ork

Logi

nre

qu

ired

No

Yes

Spec

ial“

GIN

A”

req

uir

edfo

rsh

ared

“loc

kdow

n”

mac

hin

esN

o,th

eEM

Rau

tom

atic

ally

clos

esal

loth

erap

pli

cati

ons

atvo

liti

onal

orti

meo

ut

logo

ffY

es,b

ecau

seof

CC

OW

tech

nol

ogy

dis

cuss

edab

ove

asp

ecia

l“G

INA

”(n

otth

est

and

ard

Win

dow

s©“G

INA

”h

adto

beu

sed

onlo

gon

and

logo

ffby

each

use

rC

lien

tso

ftw

are

req

uir

edN

oY

esU

ser

can

free

lym

ove

betw

een

dif

fere

nt

app

lica

tion

sN

o,ce

rtai

nap

pli

cati

ons,

spec

ifica

lly

CPO

E,re

qu

ire

the

use

rto

com

ple

tece

rtai

nta

sks

wit

hin

the

app

lica

tion

befo

resw

itch

ing

toan

oth

er

Yes

,war

nin

gsge

ner

ated

byC

CO

Wte

chn

olog

yif

atte

mp

tis

mad

eto

chan

gep

atie

nt

inon

eap

pli

cati

onw

hen

task

sn

otco

mp

lete

din

anot

her

app

lica

tion

Serv

ersi

de

cros

swal

kta

ble

req

uir

edfo

rlo

gin

pas

swor

dad

jud

icat

ion

No

Yes

f o r m a t i c s 7 8 ( 2 0 0 9 ) 386–390 389

the first CCOW application. Additionally, when multiple caregivers use a single machine, a special “GINA” must be createdthat logs off all the applications the first user was on (assumingthat user “walked away” from the computer without loggingoff the domain, which is very common at our institution), andthen logs the next user onto the domain with their uniquepassword. This takes another period of time that was unac-ceptable to our test clinicians. This issue is not seen with theGSM portal as logging off or a timeout of the “parent appli-cation” automatically closes all other GSM applications thatare open. The next user just logs on to the parent (in our case,our EMR application) just as they would have done before weinstalled GSM.

The user may move freely between any CCOW compliantapplication and receives warnings when attempting to changepatients in one application when another application is in themiddle of a specific ordering pathway in the case of CPOE orcreating a direct entered clinical note in the case of the EMR.GSM has limitations in this regard depending on the applica-tion that is currently active. In some cases if the user returnsto the parent application and changes patients, they may losedata in the previous application without a warning. Again, thisability of CCOW comes at the cost of installing client side code(in our case in almost 6000 machines) and keeping this code upto date. Finally, GSM requires no server side crosswalk table oflogins/passwords to be managed as long as users have estab-lished logins to all the GSM capable applications, while CCOWdoes require creation and maintenance of such a table whichcreates problems of coordination between different Informa-tion Systems divisions and Hospital and School of MedicineDepartments when users arrive and depart the Health System.

5. Discussion

We entered the world of integration of disparate applicationsassuming that we would use the latest technology (CCOW)to eliminate multiple logins and passwords and the neces-sity of choosing a patient again in each application opened.We employed two of our senior programmers experienced inJava, SQL, DB2, and Websphere who spent months learningthe CCOW standards and in particular making our legacy EMRapplication CCOW compliant. With CCOW being such a newtechnology we were constantly applying patches to the CCOWapplication itself. As we delved deeper into the infrastructureof CCOW, we found that it would not serve its purpose for ourlegacy application (WebCIS) that we made CCOW compliantwithout major changes to our thin client architecture that iscompletely WEB based. This forced us to add an SSO applica-tion that needed to be interfaced with the CCOW applicationitself as well as each medical application. It took us a full yearto get CCOW and SSO operational for our three main clinicalapplications, two of which were CCOW compliant and one ofwhich was not. Though user testing showed acceptance of theresulting functionality, the amount of infrastructure changes(and resulting dollar cost) proved to be prohibitive. The main

infrastructure changes included fat clients installed and man-aged on all desktops, installation and programming of theCCOW application itself as well as programmatic changesto the touted CCOW “compliant” applications themselves to

390 i n t e r n a t i o n a l j o u r n a l o f m e d i c a l

Summary pointsWhat was already known on the topic

• CCOW (Clinical Content Object Workgroup) was devel-oped some years ago as part of HL7 standards in orderto automatically pass User ID’s and Patient Contextin the background between disparate clinical applica-tions.

• Many Vendors tout their applications as being CCOWcompliant.

• No peer reviewed literature exists on the actual imple-mentation and user acceptability of CCOW standardsamong disparate clinical applications.

What this study added to our knowledge

• Vendor applications that claim CCOW compliance donot necessarily work as designed.

• CCOW requires client side software as well as server-based software thus making thin client WEB-basedapplications no longer “thin”.

• Implementation of CCOW is complex, time consumingand requires multiple vendor interaction and cooper-ation.

• The same result (with some sacrifices of full function-ality of CCOW but acceptable to end users), can beachieved with a lightweight “Global Session Manager”with a less complicated architecture and much less

r

[

[

[

[

[

va.gov/vdl/documents/Clinical/Pharm-Bar Code Med

development time.

allow them to actually work with our CCOW vendors appli-cation, creation of a special “GINA” for clients that allow formultiple users to log in and out, and building a special pro-gram to mimic CCOW functionality within our one applicationof the three that was not CCOW compliant.

Developing the lightweight GSM portal toolkit providedby one of our application vendors, using one of our seniorprogrammers who initially worked on CCOW, to accomplishalmost the same thing that CCOW provides took only 1 weekand eliminated all of the infrastructure and cost issues ofCCOW. Since we already owned this toolkit, the only added

cost was the personnel costs of a week of developmenttime in adding a small amount of code to our three mainapplications and testing. Our pilot testing and now use bystaff in the production environment has proved the func-

[

i n f o r m a t i c s 7 8 ( 2 0 0 9 ) 386–390

tionality of the GSM portal to be acceptable despite therequirements of choosing a “parent” application (our “homegrown” EMR) initially to launch the rest of the disparate ven-dor applications (nursing suite, and CPOE to date with otherapplications planned to be launched by the “parent” in thefuture). The loss of the robust warnings from the other appli-cations that CCOW provides when a patient context is changedin the parent application has not proven to be problem-atic after operational user training and experience with theportal.

In retrospect, we would not have embarked upon the devel-opment of CCOW at all if we had known that the functionalityof a lightweight GSM manager would be almost equal tothat of applications launched in a CCOW environment. Also,most applications are now heading towards service-orientatedarchitecture (SOA) [6]. With SOA, a service call to other specificportions of another application can be made without callingthe entire application. When applications support SOA, wesuspect that CCOW will disappear as a solution for applicationintegration. We urge others considering CCOW implementa-tion for disparate application integration to understand theinfrastructure changes and development time required whenmuch easier solutions provide close to the same functionalityfor the end user.

e f e r e n c e s

1] R.G. Berger, J.P. Kichak, D.L. Brooks, L.C. Kammer, U.A. Brucker,T.A. Stiffler, J.E. Hammond, University of North Carolinahealth system: evolution of the paperless electronic medicalrecord at the University of North Carolina, in: Proceedings ofthe Healthcare Information and Management System Society,vol. 1, 2000, pp. 47–53.

2] D. Manos, Institute of Medicine urges national electronicdatabase of patient records, Rep. Med. Guidel Outcomes Res.15 (2004) 1, 5-1, 6.

3] R.L. Simpson, Computer-based patient records, Part II: IOM’s12 requisites, Nurs. Manage. 22 (26) (1991) 28.

4] D.W. Rucker, A.W. Steele, I.S. Douglas, C.A. Coudere, G.G.Hardel, Design and use of a joint order vocabulary knowledgerepresentation tier in a multi-tier CPOE architecture, in: AMIAAnnu. Symp. Proc., 2006, pp. 669–673.

5] Internet Google search performed 3/24/08 on key words“Clincal Content Object Workgroup”; resulting page: www.

Admin (BCMA)/psb 3 um appendixc ccow r0806.pdf.6] P.M. Nadkarni, R.A. Miller, Service-oriented architecture in

medical software: promises and perils, J. Am. Med. Inform.Assoc. 14 (2007) 244–246.