development of a tool for evaluating proximity

47

Development of a tool for evaluating proximity requirements in the programming

and design of a new hospital

Marc Pineault

Marc Pineault, MHA, CHRP

Mr. Marc Pineault is a PlanningCoordinator with the McGillUniversity Health Centre responsiblefor the analysis, assessment and deve-lopment of strategies concerned with

the planning process for a new replacement hospital.Prior to joining the MUHC, he managed a clinicaldepartment at an affiliated university community hos-pital and coordinated the development of a transfusionsafety surveillance tool for the Quebec Ministry ofHealth. Other professional experiences include; the roleof leadership within complex health care organizationsand issues related to health services research such as,information systems, patient satisfaction, occupationalhealth and safety of health care workers.

Abstract:In the context of planning a new replacementhospital, proximity requirements between indi-vidual services are captured when developing afunctional program (FP). Accommodating thelist of requirements is daunting in an organiza-tion such as a university teaching hospital whereservices are complex, multiple and diverse bynature. Yet, the performance of a given design isdirectly conditioned by its ability to meet theobjectives articulated within the FP. It is oncethe FP is interpreted by professionals and trans-lated into a design that the feasibility of respon-ding to these requirements can be evaluated.Ideally, this should consist of an efficient andsystematic appraisal of the proposed design withregards to the program. The purpose of thispaper is to develop a generic assessment toolcapable of evaluating the level of fit between theproximities requested in a FP and a particulardesign. Once developed, this tool will be used

to evaluate a specific architectural project interms of its ability to accommodate the proxi-mities. The tool will be assessed through theuse of the pre-concept developed for theMcGill University Health Centre (MUHC).This exercise could also potentially serve as acomponent in evaluating the pre-concept.

Key words: proximity requirements, functionalprogram, planning tool.

1. IntroductionPlanning for the new MUHC started in 1994and preceded the administrative merger of fiveMcGill University teaching hospitals in 1997.The activities leading up to the developmentand completion in 2002 of a Functional andTechnical Program (FTP) included a broad-based consultation process in 1997, a number ofTask Forces that addressed strategic and opera-tional issues in 2000. This followed with thedevelopment of a Master Program in 2001 out-lining strategic directions for the new facility.

The purpose of a Functional and TechnicalProgram is to provide the most complete repre-sentation of the future complex through the uti-lization of narrative descriptions, numbers, andconceptual designs. It contains operatingassumptions for each functional unit (i.e. staffingand hours of operation), an enumeration of thespatial areas (i.e. type, number, surface areas andproximity requirements) as well as a descriptionof the construction and systems supportingthese activities. This study extracted the infor-mation from the MUHC Functional Program(FP) pertaining to the proximities.

Proximity requirements are a sub-set of opera-ting assumptions that describe the specific

BackUp_8425_Research_1 04-06-16 17.14 Sida 37

DEVELOPMENT OF A TOOL FOR EVALUATING PROXIMITY REQUIREMENTS ...

International Academy for Design and Health

48

relationship needs between different functionalunits of a facility. Hospitals are complex facili-ties in terms of the sheer number of proximityrequirements necessary for ensuring the func-tionality of numerous, diverse and highly inter-connected activities. The optimization of theseproximity requirements facilitates the attain-ment of desired operational efficiencies, as wellas provides the conditions for the developmentof key synergies between the different missions(clinical, teaching and research) that constitutean academic teaching hospital.

In the case of the MUHC, the development ofthe FP was led by a health care consortiumhired to manage the process. The FP was car-ried out by more than 800 participants involvedin 73 different work groups, composed of healthcare professionals, physicians, administrators,patient representatives and volunteers.Through a series of meetings, the consultantsgarnered qualitative and quantitative informa-tion in order to develop the FP documents forthe various workgroups.

Once finalized, the FP was handed over to ateam of architects mandated to develop a preli-minary architectural design (pre-concept).The pre-concept served as a communicationstool for discussions on the MUHC project withvarious levels of government, communitygroups as well as internal stakeholders. It alsoprovided valuable information in regards to theability of the land to accommodate the plannedactivities within the constraints of an urbanenvironment.

2. ObjectiveThe objective of this exercise consists in deve-loping a generic assessment tool capable ofassessing the level of fit between the proximiti-es requested in a FP and a particular design, aswell as to identify specific recommendations forimproving the tool. The MUHC FP was usedfor this exercise and in the evaluation of thepre-concept, in regards to the attainment of theproximity requirements outlined within the FP.

3. Data Sources At the initial stage of this exploratory investiga-tion, the "pre-research" phase, the identifica-tion of available information on the subject wasexplored. The decision was made to concentra-te this phase on data analysis, in the belief thatthis would then provide the information neces-sary to better identify a particular field ofresearch befitting this study. Ideally, in thefuture, a search for published articles describingthe development of similar tools for assessingproximity requirements within a hospital designshould be included. In addition, it is believedthat this would provide an avenue for the vali-dation of this exercise, for honing the researchtool and for ascertaining the potential contribu-tion of this study to a specific field of research.Therefore, for the purpose of this exercise, theonly information used was derived from theMUHC FP narratives and the architecturalpre-concept.

4. MethodologyThe methodology consisted of three mainsteps: FP data extraction, pre-concept dataextraction and data analysis. Upon initial revi-ew, 699 requests for proximity were identifiedwithin the FP and over 93 different adjectives,including schematic diagrams, used to describethem. The information was refined prior todeveloping a database that would be used toperform the analysis. Figure 1 schematicallypresents the process that was followed. The fol-lowing sections explain in more detail the stepscarried out.

4.1 FP Data extractionIn the FP data extraction phase of the study,two major steps had to be completed: first,extraction and classification of the proximityqualifiers and second, classification of the unitsor services.

4.1.1 Proximity QualifiersThe first step consisted of extracting and organi-zing the descriptors used as proximity qualifiersin each of the FP narratives. The 93 qualifiers



49

identified were either in the form of diagramswith or without arrows, with or without suppor-ting narratives, or just narratives. Some of theadjectives used were similar, such as near andnearby, whereas others were different forexample direct versus immediate access.Proximities were not identified in all of thedocuments. The collection of this informationwas not performed systematically or consistent-ly amongst the FP groups. Thus, the level ofdetail and type of information varied conside-rably from one FP narrative document to anot-her. Table 1 provides examples of proximity

qualifiers found in the FP. The adjectives foundwere then sorted alphabetically and groupedwithin the classification system described below.Table 2 presents the categories chosen forregrouping the adjectives and their definition.This was necessary in order to refine and redu-ce the different types and sheer number of qua-lifiers that were identified. The process for theclassification of each request was based on a con-sensus amongst the workgroup members whoanalyzed the proximity requests found in the FP.An urban analogy was used to categorize theproximities, describing them within specifiedand limited boundaries.

The selection of terms, commonly used, intro-duced a concrete notion of actual distancesbetween two points that are easily understood bymost people. This helped to avoid employingcategories such as close, near, or far which aremore open to subjective interpretations.Furthermore, it lends readily to the campus styleconcept commonly used to describe the projectand relates to an intellectual city composed ofdifferent missions bringing together resourcesand services for a specific purpose.

Table 1 - Examples of proximity qualifiers

Adjacent to

Direct adjacency

Contiguous

Primary adjacency, secondary adjacency

Lowest priority adjacency

Nearby

In same area

Timely and convenient access




50

Table 2 - Definition of Proximity Categories

Level Category Definition Health Care Context

A Neighbour A person who lives near or A service directly beside another next to another service or department

B Neighbourhood A district Pavilion / Service groupingC City A large and important town Campus / Site

4.1.2 UnitsUpon classification, this information was usedto form a basis for the creation of the proximitydatabase. However, each of the requesting unitswas first coded in order to ensure they were allcaptured. The "units" consist of the differentservice areas or departments found within theFP space program. In some cases this involvedthe creation of additional numerical units inorder to indicate a proximity request generatedfrom a sub-unit within a unit. For example theFP for the cancer centre is composed of threedifferent sub-units, chemotherapy/infusionunit, outpatient clinic, and oncology day hospi-tal. The addition of a code was necessary forthese sub-units because they specificallyrequested a particular proximity in relation toanother unit; yet they were grouped as a singleunit in the Cancer Centre FP. In this text, unitor service is used interchangeably.

4.2 Pre-concept Data ExtractionThe next step was to extract the informationcontained in the architectural pre-concept.The pre-concept is an optional step sometimesperformed prior to the design phase. The archi-tectural pre-concept for the MUHC was execu-ted for three reasons. First, to verify the degreeto which the proximity requirements called forin the FP could be met in a complex of this sizeand within the constraints of a three-dimensio-nal environment. Second, to address for thefirst time the ability of the selected site to meetthe requirements contained in the FP for thenew MUHC complex, especially regarding theurban planning considerations. Finally, the pre-concept provides an illustration of the futurecomplex, a tool necessary to negotiating zoning

changes, as well as to supporting communica-tion initiatives with the public at large.

The pre-concept architectural plans were crea-ted with an AutoCAD software, which allowedfor the measurement of the compatibilitybetween the FP proximity requests and the sug-gested proximities in the pre-concept. Withinthese plans, an identification label was placed atthe geographic centre on each floor and foreach service identified. Distances between all ofthese labels were then measured using a com-puter program written in AutoLISP. This pro-gram retains and compares the parameters ofeach label in terms of the service, the floor it islocated on, the area of the building it is locatedin, and the spatial positioning of its geographiccentre (x and y coordinates).

Data output from the AutoLISP program wasthen input into a database in text format whereeach line of information corresponded to adistance between two services. The pre-con-cept yielded 18,721 couples (a pair of unitsrequiring proximity to each other). This datawas then imported into an Access table, fromwhich an analysis of travel distances betweenservices and an analysis of the proximityrequests were conducted. Time was used inste-ad of distance, based on the assumption thatpeople have a better sense of time measurementthan an ability to evaluate distance travelled.Also, this provided a common denominator forvertical and horizontal displacement. Next, anexperiment was conducted to estimate a per-son's average horizontal walking speed. Theresults of this exercise set the speed at an avera-ge of 5.01 feet per second and constituted the



51

first element of time travel that was established.A second element factored into the equationassumed that the vertical travel speed was half ofthe horizontal travel speed and placed it at 2.5feet per second. The third element took intoconsideration the number of elevators necessaryfor travelling between two services. Therefore,horizontal travel was considered to be the speedof a normal person walking and vertical travelwas considered to be elevator speed.

Other parameters could have also been introdu-ced into the time travel calculations but wouldhave involved further investigation for theirinclusion in this study. For example, factorsthat impede travel such as obstacles in corri-dors, traffic, and chance meetings would incre-ase overall travel time of an individual. Also,alternatives to horizontal or vertical travel suchas mechanical sidewalks or stairs were excludedfrom the study. Nonetheless, the same formulathroughout to ensure consistency in the hand-ling of the data.

Figure 2 is a visual representation of how themeasurements between the couples were calcu-lated. Two examples help to illustrate the pro-cess adopted. The tags H1, H2, H3, and H4

Figure 2 - Visual representation of the measurement method

represent horizontal travel, while V1, V2, andV3 represent the vertical travel paths. The travelpath between Unit A and Unit B is representedby the hyphenated line and involves 1 horizon-tal path (H1 and H2) and 1 vertical travel path(V2). The travel path between Unit A and UnitC is made up of 1 vertical path (V1), followed bytwo consecutive horizontal paths (H3 and H4),and ends with a second vertical path (V3).

4.3 Data AnalysisThis section describes the data analysis conduc-ted subsequent to the completion of the twosteps (FP proximity requests and pre-conceptanalysis) described above.

From the original data set of 699 requests fromthe FP, 70 requests were eliminated for the pur-pose of this analysis because they were placedwithin the same functional area in the pre-con-cept. For example, in the oncology ambulatorycluster, the oncology day hospital requestedproximity with the chemotherapy/infusioncentre. In the FP, these are listed as two distin-ct entities that were placed in the same functio-nal area in the pre-concept, therefore had thesame tag. Of note is that in another design,these two units might not necessarily be located




52

in the same area and that a more refined designwould enable us to identify the exact location ofboth units in the design. The time travel mea-surement between these two points would havebeen equal to zero, since they were both identi-fied in the pre-concept by the same label or tag.A number of requests were also eliminated fromthe analysis since they were not specifically dealtwith in the pre-concept and therefore could notbe tagged or labelled in the pre-concept (i.e.helicopter pad). Data analysis for this study wasdone on 629 requests for proximities in the FPand identified in the pre-concept. This is a con-sequence of the pre-concept not having achie-ved the same level of detail expressed in the FP.

In order to simplify the presentation of results,the FP units were grouped according to familiesof similar hospital functions. The families usedto regroup the different hospital functions are:

• Administration - includes senior administration, foundation, auxiliary

• Ambulatory - includes outpatient clinics, dayhospitals, emergency

• Clinical support - includes pharmacy, clinicallaboratories

• Diagnostic and treatment - includes imaging,operating suites

• General support - includes housekeeping, security, installation maintenance

• Inpatient - includes wards, ICU

• Public spaces - includes amenities, patient resource centre

• Research, and teaching - includes faculty offices, conference centre, library

Table 3, below, describes the distribution ofproximity requests by hospital function or fami-lies. The numbers highlighted in grey representcouples where both members come from thesame family. For instance 26 couples from theambulatory family requested proximities betwe-en themselves. To illustrate such a couple is theproximity request between the cardiology/pul-monary ambulatory cluster and the emergencydepartment. All the numbers that appear belowthe grey boxes forming a staircase are requestsbetween units belonging to different functionalfamilies. For instance, 54 requests involved onemember of the couple belonging to the inpati-ent family (wards or ICU) and the otherbelonging to the diagnostic and treatmentfamily (Imaging or operating rooms).

Proximity requests involving functions thatwere from the same functional family represen-ted 19.1% of the total requests. The most fre-quent couples requesting proximities belongedto the diagnostic/treatment family with theambulatory family (13.0%) followed by dia-gnostic/treatment and inpatient families(8.6%), and teaching family and ambulatoryfamily (8.4%).



53

The data set from the FP, once matched withthe pre-concept data, enabled extraction of tra-vel times for all of the couples requesting prox-imity. Table 4 presents a summary of the fin-dings relating to travel time.

Overall, the average travel time between acouple is 3.01 minutes. The range is fairlylarge, with a minimum average travel timeobserved of 0.47 minutes, and a maximum ave-rage of 8.29 minutes. The standard deviationcalculated for the data set was 1.47 minutes. Anexample of the minimum was the requestbetween the vascular surgery clinic and the out-patient pharmacy satellite (0.47 minutes) whe-reas the maximum was observed for the requestbetween the printing service and the inpatientwards (8.29 minutes).

Table 5 presents the same data set but in termsof the requested proximity levels.Requests of couples wanting to be neighboursmade up 58.7% (n=369) of all requests, with athird (33.3%) of couples wishing to be in thesame neighbourhood. Only 7.9% of couplesrequesting proximity stated that they should be

Number of couples 629

Average travel time 3.01 minutes

Minimum average travel time 0.47 minutes

Maximum average travel time 8.29 minutes

Standard deviation 1.47 minutes

Table 4 - Summary of travel time data

Level A - Neighbour Level B - Level C - CityNeighbourhood

Number of requests 369 210 50

Average travel time 2.91 3.09 3.43

Median travel time 2.69 2.99 3.13

Minimum observed 0.47 0.61 1.46

Maximum observed 7.82 8.29 7.89

Standard deviation 1.48 1.46 1.34

located on the same campus. This likely unde-restimates the number of level C proximityrequests because many participants may haveassumed that their service would be located onthe same campus. Therefore they may not havefelt the need to express a proximity request.The table also shows that the averages per levelof proximity follows the logic that A travel timeis smaller than B, and B is smaller than C. It isimportant to note that the analysis did not reve-al an important difference between the averagesof the three different levels. The modest difference between the three levelsof proximity could be explained by the following:

1. When the users were asked to express their proximity requirements, the interpretation of the terms may have been inconsistent.or

2. The architects may have relied more heavilyupon their experience rather than following the FP narratives in a strict manner.or

3. This may have been in response to other project constraints, (e.g. costs) when developing the pre-concept.

Mining this information further the distribu-tion of average travel time between the levels ofproximity was examined. In order to explorethis distribution the average times were catego-rized into intervals of 0.25 minutes (15seconds). Figures 3, 4 and 5 illustrate the distri-bution of the proximity requests by level.




54



55

After comparing the three previous tables, therewas an expectation that the figures would dis-tinguish the distribution of average travel timebetween the different proximity levels (A, B, C).However, upon examination it became apparentthat any conclusions based on this informationwere limited at this stage of the tool's develop-ment. This may be due to the treatment (cate-gorization) of the information retrieved fromthe FP and the subsequent translation of thisinformation by the architects in the develop-ment of the pre-concept. Notwithstanding,these figures point to areas for potential impro-vement of the tool as well as interesting infor-mation for assessment.

One element highlighted by these figures wasthe existence of outliers for each of the proxi-mity levels (i.e. A, B, C). For example, in Figure3 the number of couples with an average traveltime of 7.75 to 8 minutes, is clearly identified.This information could be exploited by identi-fying the couples represented in this interval so

as to determine means to improve travel time.

Another interesting aspect was the distributionof the proximity levels according to memberaffiliation to clinical versus non-clinical func-tions. The clinical function category groupedthe inpatient, ambulatory, diagnostic/treat-ment, and clinical support functions. Theremaining functions were considered to be non-clinical, or not directly related to patients. Thuswe created three categories of clinical "presen-ce" that were attached to the 629 couples: C2 -couple with 2 clinical functions, C1 - couplewith 1 clinical function, and C0 - couple withno clinical function.

Table 6 shows the distribution of number ofrequests and average time travelled by level ofproximity.Overall, couples made up of 2 clinical functions(C2) and 1 clinical function (C1) had a loweraverage travel time than did the couples with noclinical services (C0).




56

Couples with no clinical services had a higheraverage travel time when they had requested ahigh proximity level (level A - 4.70 minutes) incomparison to when they had requested a lowerlevel of proximity (level B - 4.37 minutes, levelC - 4.00 minutes).

Interpretation of results must be done cautious-ly due to the low number of cases in the C0category as well as in the level C category.Nonetheless, the data may shed light on howthe architects processed the information fromthe FP in developing the pre-concept.Intuitively and based on their experience, theymay have started by placing the clinical compo-nents and then the non-clinical components inthe design. It also may indicate that proximiti-es are not the only factor in developing anarchitectural concept.

4. ConclusionThe objective of developing a generic assess-ment tool, as described throughout this paper,was met. In particular, the tool has the abilityto sort FP proximity requests by level of impor-tance from the FP and translates this informa-tion into distances between units in the pre-concept. This enabled a systematic calculationof the average travel time between units. Inaddition, this initial phase has enabled us tobetter identify future exploration in the litera-ture to identify existing fields of research. The

added valued of this exercise is that it has pro-ven helpful in identifying issues that need to becarefully considered at the FP stage of a pro-ject. This also will enhance the tool's ability toevaluate an architectural design. As well, theexercise has resulted in the identification offuture opportunities to expand the evaluationcapacity of the tool and are described below.Finally, this analysis provided an opportunity toconsider potential "gaps" in the informationprovided in the FP.

That being said, the tool requires further refi-nement. The following recommendations high-light key factors that would help improve uponthis initial work.

6. Recommendations• The use of a predefined framework for theidentification of proximity qualifiers was notemployed throughout the FP process. A syste-matic classification of this information with theusers in FP groups would eliminate the need fordeveloping one after the fact. A standardizedframework that classifies levels of proximity in aconsistent manner would increase the validity ofthe scale developed from a "softer" data sourcethrough the identification of the proximity qua-lifiers.

• The tool can be used for identification of prox-imity outliers in formulating recommendations



57

for professionals for improvement when futureiterations or revisions to the project design aremade.

• The assessment tool could serve to measurethe impact of design decisions or modifications.For example, in subsequent designs a decisioncould be made to optimize the particular traveltimes for the A-level requests in exchange forone greater than the average travel time for theC-level requests. This analysis could also beperformed when mechanical forms of transpor-tation are introduced or enhanced within thedesign (e.g. moving sidewalks, rapid elevators,increased number of elevators) evaluating it interms of improved achievement of proximityrequests as specified by FP participants.

• The adoption of travel time can be used as astandard measurement to validate the intent on

the part of the user requesting the proximity.For example, for user X, does a 3.5-minute tra-vel time to unit Y meet his/her expectations fora requested proximity.

• The effect of alternatives to transport, such asinformation technology and automation, shouldalso be incorporated into the diagnostic tool.This capacity would enable the tool to evaluatethe introduction of new technologies that maynot exist currently but may be necessary in futu-re hospital designs.

ReferencesKurt Salmon Associates. Functional Program -McGill University Health Centre. March 2002.

Lemay, Bobrow and Associates, in collaborationwith NBBJ. Architectural pre-concept - McGillUniversity Health


development of a tool for evaluating proximity

Documents