' + .

1 ' j . .

Appl'zcation nurn.ber / turu6ro de demande;, 3 0 -2 3 ~-r ~-y3 ~-~ S~i Fxgures;~~~
r q ` v 3o3E 52 S5,5r 67 Pages; /~5 7 Bv gf, 87 .2/3 -021.5 p-P 91:26 ; . , .
.. ~ , ~ . = .
Unsca=a`~le, item(s) received w~tli this application ~ To inquire if you ea11 order a copy of the unscarmable items, please visit the CIPO WebSite at HTTP;/ICIP ,GC,CA

~ = ' =
Iiem(U) ne pouvant etre balayes Documents regus avec cette demande ne pouvant 6tre balayes, Pour --vous reasezgner si vous pguveL cona.ander tan.e capie des items ne i pouvant etre baS.ay6s, veuillez yisiter le site web de 1`OPIC au HTTP://CIPO.{GC.
i' =
, _ .
; =

i; . , k2 >BUSINESS MADE SIMPLE

A Smart Communications System For Integration Into A Workflow-Engaged Clinical Environment Alan Graves, Jeff Fitchett, Brian Vezza, John Watkins, Tom Chmara PLEASE VIEW IN NOTES FORMAT!!!
RCRTEL

This disclosure will examine novel methods for providing clinical workflow-engaged smart communications systems utilizing context-awareness and environment awareness, which can be combined by an intelligent (and possibly self learning) system to assess specific situations, determine an appropriate response and then respond by modification, generation or blocking of communications. This approach can be applied generally across a facility such as a hospital, permitting a single solution to handle multiple different and diverse workflow optimizations through engaging the workflow and allowing it to be beneficially modified.

This invention disclosure is a solution method and apparatus targeted at solving an overall business problem, namely, permitting near real time global optimization of clinical resource management. The goal of this solution is to {
improve patient outcomes, worker safety and satisfaction, and operational efficiency through timely action within an overall set of planned and unplanned events and activities in a clinical healthcare facility. By extension, this solution can be applied to healthcare optimization within a collection of care facilities with local and remote workers, as well as coordinate with a broader emergency response organization during event response up to and including disasters and pandemics.
State of the art systems include are partitioned into discrete information systems or alert systems; clusters of these discrete systems are starting to emerge with loose coupling through information system portal presentation or through common alert presentation. However, today's information systems are largely set up to either process predictable clinical workflows with no reference to the situation, or present alerts with no reference to the overall situation of multiple workflows either in progress or scheduled.

The solution enabled by this invention disclosure adds a layer of real time information synthesis from discrete environment and context sources and aggregate decision making to automate environment and context aware communications and collaboration. Further, the decision making system feeds back to the various subsystems the decisions it makes as well as pipelining further information requests to the discrete systems. Thus, the limitations of today's systems are overcome. {

There are multiple areas for communication in healthcare, especially within a hospital which has a very complex structure, multiple clinicians and multiple functions. The fall into multiple categories and classifications, some of which are: -- Clinical/non-clinical communication - Routine/ emergency communication within clinical or non-clinical processes and workflows - Clinical data delivery/collection, support, collaboration and order communications - Clinician-clinician, clinician-patient and non-clinical communications - Person-person, person-machine and machine-machine communications - Etc. etc.

Each area can be independently optimized and a solution introduced (e.g. a "CPOE" system or a "nurse-calP' system) or an overall "universal" solution can be sought. The material provided here addresses how to create a"Universal solution" handling multiple disparate aspects of hospital clinical and non-clinical communication simultaneously while enhancing the effectiveness of workflows using these communications.

Environmental Awareness, Context Responsiveness Physical environment - awareness Environmentally Location, identifioation, sensing AwareSofutions Communications (voice, video, deta, voice- EnvironmentAware &
as-data, video-as-data ) Contexti Respdnsive Sofutions Context - Adapting behaviour based upon situations Context Responsive Authentication, roies, status, security, Solutions environment, transaction content >EnvironmentafiyAware Solutions = Use information recovered from environmental monitoring (e.g. location or sensors) to modify responses or activities = E.G. The emergency "Code Blue"is in room 392 - where is the nearest physician and crash cart?
>Context - Responsive Solutions = Modifying network responses / activities based upon on situation-contextual and information-contextual information derived for one or more sets of input data points or planes, such as known parameters of users, groups, environment, transaction content, source or destination, security, privacy, institution policies, staff skill sets, task or situational skill requirements, location and utilization of equipment or any other similar set of attributes = E.G. The emergency 'Code Blue" tearri requires a set of skills - establish contact to on-duty clinicians with those skills >Context - Responsive & Environment Aware Solutions = Modifying network responses or activities based upon on combining contextual decision-making and environmental inputs to determine a course of action (e.g. known parameters of users, groups or known situations plus using data recovered from environmental monitoring) to modify responses or activities = E.G. A"Code Blue'has been calied in room 392- Determine the matching key set of required skills, which clinicians have those skills and where the nearest available (non-busy) on-duty clinicians are with those skills to the 'Code Blue"site - those are the Clinicians contacted first 3 nor~ con~u.i i~ro,m The above chart provides a view of the environment and context-aware aspects of the system The above provides a diagrammatic view of an Environment and Context Aware solution We can create and apply an Environment and Context Aware smart solution to a hospital by providing the following....

a) An environment and context detection capability across the physical site of the institution, which may consist of arrays of sensors, location technology and the processing of these devices data output to deduce basic identification, location/tracking/proximity and significant sensory information b) Processing of the resultant context information from a) by combination with the institutional contextual data ( such as policies, staff skills lists, duty rosters, patient ID's, medical status) and communications activity or requests, the whole being processed to determine what course/courses of action are appropriate for the derived circumstances and modifying, initiating or terminating forms of communication as a result.
c) The modification of the delivered communications via the software-controlled communication infrastructure so as to advance the clinical effectiveness or achieve other appropriate and beneficial goals A Possible Hospital ECAS Solution ~
Institution policies and practices, operational requirements, staff duty rosters, skdl sets, patient assignments, etc.
ormation & wod bws stems Institution Information s stem Hos ital Clinical Hospitaltion Radiology Clinical imaging data, patient p Infonna Informatbn image data, clinical assessments Information System System System from images Institutional context =
what is allowable (policy Clinical data, patient interpretation and data, clinical status appl~ication), what the Institutional resoumes available are - --\ __ --- ---------- ---------- 1-1 ... ...
Data flow adaptation, generation and blocki9 n context (skr7equlls, pment dutyhst),roster, ._._._._._ _ ._._..P.._.9._._._.. ._. .- .~ processin what is g normal under the .. ._ ._._._ o about ---"-----'-- circumstances (history) and how to g Users Comms something (procedures Hospital data and voice ica !o Decision making as Code Blue, comm ni io infrastructure comma g Yellow, Red) v ~m Authentication7 engine pv,al Equipmenl : Authentication. unicationsr ysis &
I equesfs Reportin Environmentally aware Situational Agent(s~
context information processing processing Input o ,--__--- ----------__ ____.-___-envi mm Mal Sensors Location, Identifcation Situational context =
environmental prnnft,es, -multi- tracking & -Foreach context+useractiv8y/activity gatheri environment prChoximitnicianys entity requestcontext - requin;sin-feeds --Inputs to -Patients authentication of communications activity as well -Equipment as environmental situation -Other Note- several options shown in figure S 1brte1 ccnneannsf 1NCrmauen This figure shows a possible hospital smart environment and context-aware solution. The "conventional" Institution Information System and Hospital Data and Voice communications system are complemented by an environment-aware data gathering and processing function which can feed a situational context processing function, the other input to that situational context processing function being the human and machine activity within the institution. The situational context is fed to the institutional context processor which can garner appropriate institutional data (policies, permissions, skill sets, stored patient information, etc.) and determine the appropriate institutional context for the situational context. This is fed to a decision making engine that, based upon the situational context and institutional context, determines the required action which may encompass allowing or blocking communication (e.g. blocking access to files where permissions are inappropriate), modifying communication, either in content or format or generating communication (e.g. for forming a Code Blue team). The decision making engine can interact directly with the pre-existing communications infrastructure or with a data flow adaptation block or both to achieve its ends.

This figure maps the various layers of activity and processing required for an effective Environment and Context aware solution, based upon a known analytical technique - OODA

Potential Impacts of ECAS Contributions -, ofz Clinical Grade ECAS Contribution Impact Tenet Availability In case of equipment faihue location and Increased avaitabiNty during times of identity of users can be used to adapt the partfai system failure. t_xposure of protection response to ensure adequate equipment to out-of-spec environments coverage for critical users can be detected and alarmed.
Security Location based identificatfon and tracking Prevent theft, prevent losing elderly, of people, objects, location and sensor very young patients, improved clinician (biometric) assisted Iog on and identification, authenircztion, improved authentication, authentication duration information security. Access prtviteges based on clinician-terminai proximity and into network can be dependent upon location, detection of suspicious location movement of unattended terminal, cyber-'caraliing' of equipment Quality of Service Identify clinician terminal needs, QoS characteristics modified according (QoS) $ capabilides, connectivity, workflow to users credentials, terminal ~
~
uaranteed situatlon, user credentials 4 inputs to capabilities and workflow situation ervice Level QoS partitioning scheme (workflow- better apportionment of Agreements (SLA) optimized QoS modification) communications resources4 better emergency response, better user satisfactfon In rou8ng operation Pervasive Can identffy clinician, terminal location Higher coverage, better throughput -~
Coverage of the and provide information into adapiive better service delivery, more Facility and coverage physical layer - e.g. steerable acceptable system performance to end beyond antennas, adapfive power control user solutions or to select alternaBve delivery methods Na1NCmMw,ti4Nldna,bn These two charts show some of the expected benefits of applying an ECAS to a hospital.

Potential Impacts of ECAS Contributions-zofz Clinical Grade ECAS Contribution Impact Tenet Seamless Identification of IocaGon, userfuser profile and Shape communications to clinician mobility with context of needs -) better mobility solution needs, best available delivery session solution adaptation Transaction Integrity checks based upon location More secure, more traceable integrity transactions Non-repudiation Ability to track, log vectors of clinicians, patients, Easier creation of event histories, establish and log temporal-spatiai proximity backtracking to establish chain-of-occurrences, events Provides ability to Enable new location, environment and context- Better user experience with hand-evolve - "future- based services infrastructure, aikwv the held usage, less hand-held losses proof" widespread use of handheld devices, by mapping encourages adoption, more communications content to match context of capable, Intuitive and ":mission-terminai oapabiiities, connectivity, provide theft optimized' future services protection for portable devices Human-system Using iocation, proximity, clinician profiles to Easier, more convenient clinician interactions - better tailor the data the ciinician is presented interaction with infonoaBon ease and with, simplify, reduce authentication processes technology, delivery in form consistency Whiie -emaining secure appropriate to clinician-network link, clinician situation Workflow Understanding clinician associations, situation, Easier, more convenient clinician engaged kocation, proximities, etc. alknvs communication interaction wkh information form and content to be adapted more technology, better formed, appropriately prforitrzed infonnation delivery, in form appropriate to clinician-network Ilnk, ciinician situatbn ~ t xaw cana.,wi uaw,~m-, These two charts show some of the expected benefits of applying an ECAS to a hospital.

Emergency In-Building Applications (Hospital) > Emergency (E) "Code" - various emergency codes indicating the activation of an emergency protocol Different hospitals define these differently - some are fairly universal Code Bluelpink- emergency cardiac/respiratory event - adultlpediatric - Form resuscitation team +
equipment @ site, followed by Ohio Emergency Codes urgent PoC encounter CODE NAME EVENT
Code Adam - Missing infant I child Fire Response to potential child codeadam tntanuchudabduaton abduction with facility lock down, Bomb/Bomb Threat security sweep Codo Cray Severe Weather Code Brown - Wandering patient Code Orqnge Hazardous Matedal SpIIURelease protection Medlcal Emergency =Adutt - Urgent location of patient (usually Code Pink Medical Emergency - Pediatric elderly) to prevent injury Code Yellaw Disaster Code Violet - Violent patient Violent Patlent/Combatlve - Security to patient site to prevent C 0~ st+ver Person with Weaponl risk to clinical staff, other patients Hostage Sltuatbn Missing Adult Patient 12 non iConraaneannformanoo DoctorsHospital,OhioEmergencyCodes Emergency In-Building Applications (Hospital) > Emergency (E) Code Yellow - Disaster Response - Hospital -> emergency basis to deal with large number of incoming wounded Code Red - Fire - Implement fire evacuation and containment protocols Code Orange - Hazardous Material - Implement HAZMAT evacuation and containment protocols Ohio Emergency Codes Drug theft or tampering detection CODE NAME EVENT
- Expensive/narcotic drug loss Fire prevention and patient protection cc d- Ad- Infanttchlld Abduction Equipment theft or movement Bomb/BombThreat outside of authorized zone code Gray Severe Weather - Equipment loss/misplacement coae Orange !... Hazardous Material Spm/Release impacts clinical effectiveness, ~-Tn~ Medical Emer ency-Adult g equipping levels. codePink: MedicalEmergency - Pediatric - Detection deters further theft Je yeu(Disaster attempts. Vlolent PatlentlCombative - Theft of terminals = loss of Ccde Sllver Person with Weaponl private data , Hostage Situation Missing Adult Patient 13 r+onai cor,aam~i imorm,son Coctor5 Hospital, Ohio Emergency Codes ---- --------Various emergency codes and ECAS implications Ohio Entergency Codes Code Event Response ECAS implications Red Fire PariiaUlolal evacualion, fire loeation Firx1 location d'. cordbm fire, toxic produds spread (nature, coverage) and tlgMing Adarrm Mlstlng infanl 'LOck down' buHtling, seek child LocateRradc kxation tag on missing Infant w chikl, raise alann before IrAant or chikt or child andror abductor enters hazardous area or is removed from buiking, bcete all ronempbyees, vkfeo a1M sensor seardres of buikfing, auto-review of exk door video, senaor logs Blaek Bomdbomb PartlaUlotal evawiation, threst F'ad bcation of, and exislence of bomb (sensors). Identify placemerd agents from threat assessment. bomb kxcation tislorical video. ardiived sensor data.
Gray Severe Monitor buikling for darnage, move Building cnn6Non monilodng (sensors, vkieo). confinnation of employee kxation vreather staff ard paUerss as appmpdate to (espedally fw evacuated areas) iMeat, damage, prepare for incomirg casualties Or+nas 1lezerdous Identify materisl Mrest cantaln, Sensors to deted, locate and tradc release early, track spread, tradc resdual matedal neutralize and dean up, treat conlamination after clean up, identify exposed personrel and degree of exposure, spilUrelease exposed people, equlpment back exposed perspnnal contads, espedaay for biological agerR releases B7~ Medical Idemify bcatlon of patlent, rotify al Establish bcatlon and klentily of pa6ent, location, identky of alarm insBgator, iocation emeigency- 'proximate clirYcians, assemble and current aclivities of prospedive emergency response team members, form team adup emergency Iresimeat tesm, and notify team members of event location, Identlty, deGVer penlnera dinical equipmem at site in<onnation Jek Medical As'Blue' As'Blue' but first seekirg pediatric expertlse emelgenq-pediabic Yel Oisaster Assess relure ard scope of disaster. Ndify all pertinent and avallaGle personnel, form trauma, trlage teams based upon (extemal) prepare axordkgy. Clear ER of atl skills, shirls. Catalog bcatfon, current staNs of all ER and nwi-ER emergency-non-essenNal acllvkles, patients supporting eqiipment. As soon as nature of disaster, idemity of vidims Is evallable assemble diriral Irformatlon pertlnera to tlisaster responsas, vlclim records (if any) Violet Vmlerl or Restrain, calm patlerd and stabilize Detedion of patienl movemem or adiwrs indidltive of tMs state? Identify end notify cornbative patient state pmximate secunly persorcrel and any other response teams required faUed Silver Armed person Evacuate area, confain silualion with Detedion of xeapon at entry dows (smnsors), track suspeds before, after security or hostage kxal security, noUfy Iaw enPorceneM invoNemem, Iden6fy and notYy pmximate security personnel and any other response situation te6ms requked Brown Missirg adult Semi-'Lode down' dikling, seek lost Locsteltraclc bcation tag on patierR, raise alarm before patient exits buikiing, video patlerd patient and sensw searches of Mrilding, atAO-revIew of exft door vldeo. sensor logs Under7ined code - deelt with !n depth in companion docurrieM
14 rwnei cmeaennd k,l__ This chart identifies some areas where ECAS can enhance hospital Emergency operations Example** In-Building ECAS Applications (Hospital) > Routine (R) 1) Clinician coordinates location and context 2) Patient tracking and/or monitoring 3) Equipment tracking, location and condition 4) Equipment(clinician or equipment/patient association 5) Clinician Point of Care communications 6) Clinical collaboration 7) Drug safety, security and environment 8) Various applications in support areas = Radiology, Cardiology, Nuclear Medicine, Pathology, other test labs &
functions > Emergency (E) "Code" - various emergency codes 1) Code Blue/pink- emergency cardiac/respiratory event - adultlpediatric 2) Code Adam - Missing infant or child 3) Code Brown - Wandering patient protection 4) Code Violet - Violentlcombative patient 5) Code Yellow - Disaster Response 6) Code Red - Fire 7) Code Orange - Hazardous Material 8) Drug theft or tampering detection 9) Equipment theft or movement outside of authorized zone - detection ~- . .. e . -. ...- .
. .= .= = -. ..
^= the Ilst is meant to M aomprahanslw In that N will allow testing of muhiple scenarlos but Is NOT Intended to be eonplete or exhaustlve Nonel C-pdaMql Inla,-5m This chart lists a diverse set of examples of hospital routine and emergency activities and workflows, both clinical and non-clinical. This list has been used to test whether the solution really is "Universal"

ECAS Service Functional Interdependencies- high level -------------------------- --------------- -------------Hospital Clinical, HIS , HCIS `__' -Clinic~an Patient Patient Facilitv. Staffand data data Clinical data Patient databases ; ---_ and infrastructure - __'____`=
' ----- -'--Context ,: a Conventional information Clinical services - Hospital IT &
gathering & iinical Collaboration. POC, Code Blue clinical IT
lCe.g.
processing solution I R~ I
Non-ctinical services -e:o, Equipment trac mg an t e protection, drug '--- physical safety y f p~ _ ocation-proximity -I ~> based association and sensor association ian/e ui ment/patient assogiatior~ --- Environmental Awareness and Basic Environmental Awareness Context e.g. Location, sensors 16 Nahl CmftlmtiJ
The Figure shows a basic hierarchy of services and their relationship to the core Hospital Information System (HIS) and, within this, the Hospital Clinical Information System (HCIS). The four main areas in this figure are: -a) The core Hospital clinical, facility, staff and patient databases and infrastructure that makes up the HIS.
b) The conventional hospital IT and clinical IT solution elements c) The additional functions providing environmental awareness and environmental context information d) Overall context gathering and processing across the facility, leading to context/situation-based decisions within ECAS. These are then applied to modify the nature, scope and occurrence of communications.
The core Hospital clinical, facility, staff and patient databases and infrastructure that makes up the HIS can be considered to consist of two main components, the Hospital Information System, which handles the non -clinically sensitive data and information of the hospital and the closely guarded, very secure Hospital Clinical Information System, which contains the clinical data for current, prospective and past patients and which is subject to stringent Health Insurance Portability and Accountability Act (HIPAA) requirements in the US and Personal Information Protection and Electronic Documents Act (PIPEDA) privacy requirements in Canada as well as similar requirements in other countries. The HIS consists of general facility data, such as financial data, building maintenance schedules, general purpose data networking and so on, as well as a database of which clinicians are accredited, what their rights and privileges are, their work schedule and preferences including their IT preferences, etc.
Neither of these contains any clinical information about the patient base although they may contain non-clinical data about the patient base. The HCIS contains all of the sensitive clinical data and includes two resource groups, being information on the patient and clinical information on the patient. Both are required to be kept private. Information on the patient may include ordered tests, schedules, patient-clinician associations, etc. while the patient clinical data consists of EHR, EMR clinical data, clinical data, images, etc. for patients, ordered treatments, diagnoses and other clinical data that can identify the patient condition. Often the boundary between the Patient Data classification and the Patient Clinical Data classification can become blurred so both are ring-fenced inside the HCIS-Within the conventional Hospital IT ands Clinical IT solution is a relatively conventional communications and IT infrastructure, although hopefully engineered to Clinical Grade standards. This infrastructure throughout the hospital supports both Clinical Services, such as clinical collaboration, Point of care information sessions, response to Code Blue and other emergency (and routine) clinical actions, etc. It also supports a suite of non-clinical services such as may occur in any large business facility, as well as more advanced non-clinical services and clinical services arising from the application of ECAS.
The Environmental Awareness and Context area of the above Figure consists of basic environmental awareness, the detection of key environmental primitive information, such as the fact that sensors # 658-671 are reading +400 C whereas all the others are reading between +20 and +23 C, or that an item with a identity primitive of Object 893 can now be found at coordinates 453, 235,12. This information is of very limited use unless put into context by both performing location/proximity based association or sensor field analysis as well as deriving context based upon policy and information about what should be the results from the environmental primitives. For instance if sensors 658-671 were in a storage room this might indicate a serious problem like a fire in that storage room but if they are on the chimney flue of the furnace they may simply indicate that the temperature outside the hospital is very low so the furnace is working overtime to heat the building.
Information from all three areas is brought together in the fourth area, the context (or situation) gathering, processing and decision-making stage. This takes the processed information from the Environmental Awareness and Context area, combines it with policies and permissions from the core Hospital Clinical, Facility, Staff and Patient databases and infrastructure, both in response to user and network requests and activities within the conventional Hospital IT and Clinical IT solution and in order to modify the action of the conventional Hospital IT and Clinical IT solution. This may be as simple as denying access to a user based on the assessment that this is not a legitimately authenticated user or may be the rearrangement of communications services on behalf of a clinician, based upon where that clinician is, who they are with or what they are doing.

The figure shows the relationships between the various routine and emergency clinical communications and support services described in the previous two sub-sections, from a layered services and information flow perspective. At the head of the Figure is the HCIS and HIS, most of which has to exist in the pre-ECAS world. Under this are the ECAS clinical services with some grouped examples shown. These communicate with the HIS, the HCIS and the environmental layers below them. The non-clinical layer, also with some examples shown communicates with the HIS and the environmental tayers below them. The Base environmental layers receive mapping, zoning and facility data from the HIS and provide environmental input into the clinical and non-clinical services above them. This high level view can be broken down some more. The figure shows a possible structure for how the majority of the example clinical IT support services and applications can be mapped into a stnicture and the interfaces between them.
It is important to note that this is just one view of this, which is not claimed to be complete. Nevertheless this structure will teach us a lot of how these capabilities and services have to be structured internally, how they interrelate and what information has to flow between them as well as the functionality of each service or application. It also shows exampies of various types of services, where they fit and how they can relate, including how some routine and emergency services can be relatively common.
At the top of the diagram the hospital clinical, facility, staff and patient databases and infrastructure is shown. Under that is a layer of clinical services of which examples are given as El Code Blue/Pink-emergency cardiac/respiratory event-adult/pediatric, which is associated with R6 - clinical collaboration and R5 - Clinician Point of Care communications. AII of these are associated with E5 - Code Yellow - disaster response. These are associated because they share many of the same requirements, functions, attributes and information flow and connectivity requirements. Furthermore they should all present their clinical information to the end user in the same manner and have similar user profiles, although the circumstances for their use may be quite different.
Undemeath the clinical services layer is shown the non-clinical services layer. These may be services which, although not clinical services in themselves, provide vital direct support to clinical services or they may be services separate from clinical services. All of the examples shown are, in fact, emergency services although this will not always be true and some of the emergency services shown in the figure also have non- emergency equivalent services - for instance the service E9 - equipment theft or movement outside of authorized zone has a routine counterpart, not shown in the figure, for routine equipment tracking and accessing for maintenance/calibration purposes or for locating (inventory control) before a routine clinical procedure or even for an annual audit.
The services shown as E7 - Code Orange - Hazardous Material Release and E6 -Code Red - Fire have substantial commonalities, both being involved in evacuating part or all of the building, understanding the extent and spread of the fire and smoke or products from the hazardous material and identifying people and equipment at risk in the vicinity as well as helping provide data to coordinate the containment and elimination of the threat.
For the same reason - massive commonality of form and function - E2 - Code Adam - Missing Infant or Child, and E3 - Code Brown - Wandering/Lost Patient can be grouped.
E8 - Drug theft or tampering detection and R7 - Drug safety, security and environment can also be associated. This pair are shown placed slightly higher in the figure than the others since R7 would have a clinical component to it if the drug safety and tracking the whereabouts of the drugs is extended through to patient administration in which case an extension of this application can provide drug dosage verification, although this is not shown in this figure.
Below the non-clinical services are shown some of the basic Environmental Awareness and Association/Proximity/ Sensor Association functions and support services. The sensor association and data extraction function is not explicitly shown in the figure but would occupy the area denoted by a dotted box in the bottom right quadrant. The lines between the individual applications or dotted groupings of applications represent the most significant identified linkages between them. These linkages, in terms of input and output information will be detailed in the following sections as part of the discussions around the functionality of each of the applications and services. Whilst the Figure shows very complex interdependencies these are a combination of a pre-existing set of functionality and complexity required for the basic pre-ECAS HIS, HCIS and clinicaUnon-clinical applications combined with the overlay of ECAS
functions. Furthermore the ECAS overlay functions need not all be implemented simultaneously but rather can be introduced in steps as and when needed and as and when justified.

Clinician Coordinates Location And Context The objective of this application is to provide accurate, Service example - Clinician coordinates location (RI) low-latency, unobtrusive identification of clinicians' location, strictly as a private and confidential input to a) Basic location service for input to other services computing the clinician situation, needs and nature of Environmerrt I'' `s Functions outI""s more clinically involved services that are required to =õ~', ~, m' ct~n~i~, lo auon ana nac~ang rrocessing Of raw daia ro cwdaen wceaan support clinical workflow integrated, or workflow . jp ft& M f,onbCatbn determine Ginician Iocation, enabling applications being used by the tracked clinician. subbystem (cliniUan) Vector As such this is a service providing input parameters for b) Rich stand-alone location service Inputs other more sophisticated services. The attributes of this Fad~IMO~ Functions ~~n service ar0: _ = Hospital giid map, zone ~~l Clinician location and map and usage aqoatbo ~" - qlnidan bcaaon and a) Wides read use throu hout hos ital in locating and ~~~~~~
hindliOnal P 9 P ~an MD% Pmcessing of raw aau to wapp" o ~taminaitvoe determineclinicianlocatlon, Loca6oncontextkqu tracking clinicians - a high degree of facility ana E~naan medNity coverage is required in areas of the facility where ~ rdiNaana role VeCiOf ;b ~''b'"
a zone, eaner genxic or - Establieh clinician zone tracking is appropriate and no coverage where spftft odffkian,o prmnceasinputtodinician tracking is not appropriate. This may be achieved E r^"~'!~,pminvBs CO1"e7~
at the physical level or by appropriate filtering of the (GlniGan, terminal) -Establishing history of location location and Identification data before release to vzdidatin9 Girdc;an is at iocatbn other user applications.
b) Provides a location and optionally an implied context aspect to automating the optimization of multiple services, both in and beyond communications c) Provides a basis for several other services due to the ability to track the clinician's location d) The time criticality requirements of client services supported by this service are transferred through as requirements on this service. The time discrimination (latency) of this service must meet the needs of client services based on the location tracking capability.
e) Precision and accuracy - the location precision and accuracy requirements of the services this service supports transfer through as requirements on this service. Different supported services have different requirements - for instance a service that is establishing which wing of the hospital a clinician is in may have a precision requirement measured in 10's of feet or more and an accuracy requirement of 95%, whereas a supported service that involved delivering private data to a terminal based purely upon the terminal being within the clinician's personal zone may have precision requirements of +/-12 inches and an accuracy in the 99.99-99.999% range - a very tough or impossible target to meet, mainly because of the accuracy required.
f) Located entity discrimination and identification - in a mutti-entity environment the service must be able to accurately track multiple entities and discriminate their locations and identity primitives - it does not need to know each entity's real world name but must be able to identify teach entity's location identifier, so that can also be passed to the higher level supported services, which can map the kocation identifier to the corresponding real world identity, permissions, profiles, etc-g) Security - This application should be able to confirm the identity of tracked clinicians and report location and identity only to authorized user applicafions for this information - there are significant privacy issues and intrusion of personal space issues if the information is not correctly used.
h) Dependability - Higher level applications must be able to depend upon the information provided from this application, including latency, accuracy and precision of tracking and tracking the correct entity in an entity-rich environment (a crowd).
Hence the value of this solution is the ability to provide real time location-based support to other services including Clinical Point of Care communications, Clinician to clinician communications, clinician telecommunications reconfiguration, equipment theft protection, equipment maintenance, etc. Location/situation optimized services are anticipated to improve user satisfaction with the services that rely on this service, user proclivity to use those services as well as the ease-of-use of those services while also protecting the user and facility from data theft, equipment theft, and inappropriate access to data. But this can only be realized if the user has no concems about misuse of his/her location information, either by the hospital organization or third part'ies, requiring that data information be regarded as information to be kept private and secure.
The inputs, outputs and functions for this service at both a basic (support to other services only) and more sophisticated (stand alone utility) variant are given in the Figure The ECAS contributions and enablers are: -a) The Clinician location tracking capability of ECAS, from the location component of its sensor network provides input to location-sensitive services, assists in providing context-aware capabilities, which include physical world location, both to grid and by zone.
b) Location-based context awareness leads to better context-interpreted responses which in tum allows for more effective, speedier, convenient clinician support services and a higher clinical productivity with lower clinical error rates Key environmental parameters that ECAS has to discriminate for this service are: -a) Clinician location b) Clinician terminal location c) Clinician identifier and validation d) Clinician terminal identifier and validation Key Context parameters that ECAS has to discriminate for this service are: -a) None for a basic location service - context is supplied by higher level services supported by this service (Option a) in the Figure ) b) Altematively, in a rich location service context would make use of a Hospital map of functional zones and uses, Clinician ID, type and capabilities of hand-held terminal. The basic service will be assumed here since we are also examining the suite of supported services and adding sophistication to this basic service would only duplicate functionality (Option b) in Figure Service Example - Equipment I clinician / patient association (R4) a) Basic association service for input to other services Inputs Outputs FunctionFs nvironment CGniciaNpatient.
Clinician location, vedor, ID pdmitives Equipment I clinician I patient cpniciaNequipment and = Patient locatfon, vector, ID primitives association = Equipment location, vector, ID primR'rves patient/equipment Any proXimity detector outputs with - Processing of raw location data proximity event parametdc data ( range, ID of parties) to determine proximity L characteris5cs Equipment/Clinician Or Equipmentl conditions Patient Association b) Rich stand-alone association service The objective of this application is to Inputs provide an ongoing and real time Facility/clinical infonnation uncttons = Hospital gnd map. zones and usage allocaBon Outputs tndication of the relative locations of = Equipment etalzatlon hrstory Equipment! clinician ! patient clinicians, patients and equipment so = Clinician ID'e= roles, profl'e association as to allow the determination of which C ntem Processing of raw location data Equipment ID's CiinktiaNpalient, clinicians, and ul ment Zone boundaries of perrnitted equipment to determine proximity patients ~ p movement or use diniciaNequipment and medical e ui ment or Clinical IT conditions q p = Equipment utilization primitives I~~~e~~n~m terminal devices) are physically close = Clinician terminal type and connectivity - Establish , track role of clinician proxinlty event enough to each other that they satisfy Clinician role byzone with patient by zone inference ~'ac~"s~
Envirorunent Proximfty event bcation defined "association by proximity" Clinician location, vector, ID primitives -Establish history of proximity and zone ;Nwmd requirements. This information can be = Patient location. vector= iD
primitives events for each proximity possible range of = Equipment locatlon, vector, ID pdmitives combination sjWafions used to associate clinicians with patients, =
Myproxinitydetectoroutputswithparametric clinicians with equipment or patients with data (range, ID of parties -Determine equipment = Equipment condition, environment and authentication equipment in clinical applications using utilization (sensors) ECAS. 19 rw~c~~i ~wa The key attributes of this application are: -a) Continuous and widespread use throughout hospital in providing association by proximity information to Clinician support services, clinician communications and information support services b) Provides a relative location tracking capability at sufficient precision and accuracy to satisfy the needs of higher level clinical services that are clients of this application as well as computing an implied context aspect (meeting of dynamic proximity conditions such as to meet "association" criteria) allowing the automation of configuration optimization for multiple services, both in and beyond communications c) Lack of association of equipment with clinicians or support staff may indicate unauthorized usage or ,'rf equipment movement is detected, theft or misappropriation d) Low latency is important for some client applications, especially theft discrimination and as inputs to some clinical workflows or workflow stages, since otherwise the human interface and system response would be degraded. This application must meet the latency demands of client services, some of which have real-time interactions with clinicians which require this application to provide adequate time discrimination that service reconfiguration is "immediate" in human time scales, as well as other services which are based on the location tracking and association and which also have to see adequate responses-to-need.
e) Must positively identify associated parties -misidentifying non-clinicians as clinicians or misidentifying clinician identities can lead to HIPAA violations f) Dependability - this application must provide consistently accurate results for the identity and proximity of associated parties Hence the value of this solution is the ability to provide real time correlated locations and detected proximity situations meeting specified association criteria to higher level clinical services for the purposes of allowing these services to be more anticipatory, user friendly and efficient. This includes selective pre-fetching of data, discriminating between authorized and unauthorized usage, personal profile or customization downloads, services reconfiguration and many other capabilities detailed in the higher level services. It is anticipated that location/situation optimized services will improve user satisfaction, user proclivity to use the solutions, user ability to use system efficiently and effectively and protect the users and the facility from data theft, equipment theft, as well as inappropriate access to clinical data.
The inputs, outputs and functions for this service at both a basic (support to other services only) and more sophisticated (stand alone utility) variant are given in the Figure The primary ECAS contributors and enablers are: -a) Equipment/clinician/patient proximity-based association can provide input into multiple services for clinicians b) Clinician/patient association can accelerate and simplify the PoC process by pre-fetching and organizing clinical data based upon the patient's identity, clinicians authorization level and may simplify authentication, by allowing a clinician to remain authenticated all the time a terminal is within their personal zone c) Clinician/equipment association can be used to log equipment to a particular clinician, should they exit a department, zone or building together - lack of such association represents unauthorized movement or theft Key environmental parameters that ECAS has to discriminate for this service are: -a) Relative location or proximity (clinicians) b) Relative location or proximity (patients) c) Relative location or proximity (equipment) d) Identity primitives for the above Key Context parameters Location zone map of facility, proximity and association policy inputs, possible go and no go zones for equipment and/or patients The objective of this application is to provide unobtrusive Service Example -Clinician Point of Care and workflow integrated, workflow supporting Communications (R5) communication of data to/from the PoC in a secure, easy to use and dependable manner, such that the workflows surrounding point of care sessions can beneficially Inputs FuneUona Outputs evolved to become more efficient, effective, safe and c'" ' "
= EHR, EMR= EPR access PaC BnCOY11[Br mutually beneficial for the clinicians and patients by the Ta traaaa end~
,~essto,entry of = Dec¾io aM den; paaent-Identfiable ~P1~1 ~n"Bt~O"
application of information technology inside the clinical = Deciabnvalklatbn EHR,EMR,EPRetput workflow consu aaon dinicel data 7 st re uns lnpW
Ca,te,a - Decision capture and = Dxmbn and den The key attributes of this application are: - c aau ~a~a eil~sta~tr'" "
~10V8"d~01` ~ on6U'~
= Cnnicat rde Awm rochn1C I AutAenBcatlOn and cmm a) Widespread use throughout hospital in supporting ~~t~D
collalloretlon(R6)toola C1Mclenbenltyand = C1mclaNpatknt, Gmb4N - Order rec:eptlon and autMnywan pr:nlNe Clinician examination, diagnosis and treatment of patients awpmanta smb,bns(R+) placement L lb" d p mm' bcsuo" a -including fetching requested information and capturing and 7am b,dp and~
ciNcren auurenticaUon ,tft EquOnMd o disseminating generated information, decisions and orders Envtronment andpatlentassoc(aBon, eenyky coõt-elatb, = Locatbn (Glncizn, panant, term6,al) equlpment associadon b) Supports Point of Care decision-making both with the (R7-3) patient and away from the patient by providing access to information, ability to capture information and consult with colleagues c) Time critical - During patient encounters clinicians do not want to be waiting on system responses or dealing with a slow or variable system response. Examination and 20 diagnosis sessions often require several decisions in sequence so decision validation on each decision needs to be real-time d) Security - HIPAA requirements apply. System must only respond to lawful requests for action from authenticated clinicians, operating within allowable context. Patient identifiable clinical data must not be shared with unauthorized or unauthenticated third parties.
e) Dependability - If successful this approach will be deeply integrated into clinicians' workflow practices and decision-making processes so must be extremely dependable in all key attributes. This means meeting Clinical Grade, both for the conventional IT
infrastructure aspects and for the add-on ECAS components.
Hence the value of this solution is that it can provide a much greater capability, effectiveness and ease-of-use to a suite of high usage, widely used, clinician support tools specifically targeted at increasing clinical effectiveness, efficiency and reducing errors.
The clinicians' ability to exploit comprehensive data access, input and interaction at PoC simplifies and speeds up the clinical workflow, while allowing for more informed more validated decisions which can be more accurately and rapidly captured and disseminated - this is what achieves the increased efficiency, effectiveness and saves lives/reduces medical errors.. Use of ECAS with PoC tools also enhances convenience and security features which improve user satisfaction and the user ability to use system while improving the protection of the user and facility from inappropriate access to sensitive data. The inputs, outputs and functions for this service are given in Figure The primary ECAS contributors and enablers are: -a) Location awareness, proximity detection and establishing associations allows more context to be provided to the clinical applications, based on dinician-patient physical proximity, PoC location, etc.
This allows the most relevant data to be pre-fetched or to be placed at the head of a queue or list, can automate various features and can reduce clinician workload associated with accessing and using the Clinical IT system b) Context awareness enables better context-interpreted responses by higher level clinical applications which in tum provides for more effective, speedier, convenient PoC sessions c) Context-based Clinician role or situation, clinician-patient association, Clinician- equipment and clinician-terminal association, identity of clinician, terminal, patient, equipment, authentication status inputs based on location discrimination enables advanced features in multiple PoC user scenarios Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (PoC event) b) Location (first party/ session origination clinician) c) Location (patient) d) Location (equipment) e) Location (terminal) f) Ongoing dynamic proximities and associations based upon proximity definitions Key Context parameters a) Facility mappings of locations to zones, functions within zones, b) Clinician authorization and authentication, c) Clinician-patient mapping list, d) Clinician duty roster, e) Patient record access privileges, f) Patient location, patient status, g) Information connectivity system parameters, h) Information connectivity terminal properties, i) Location and use of other nearby terminals + their properties Drug Safety, Security And Environment The muttiple objectives of this suite of application Service example Drug safety, security and environment (R7) is to provide a validation that drugs are safely securely stored and handled so that theft or loss is avoided, drugs are not damaged or Inputs contaminated and that, when it is time to Faa7ey Inlormation administer the drugs to patients, that the correct -~~~= ~~ 0r~`a"
~~~en Funcdons Outputs high quality product is properly administered, ,'~
bstory, 00dr ~ `r 9esites Drug safety, securityand that drug inventory taking and (with use of c'i^~( environment = Cliniden ID. Drug ID, quarnity (by RFID scan, suitable RFID) sequencing is performed to avoid mwwiafeouy).Pr,wmacw 4 Paikffti0 -Trackingwhereabouta of ~rs~i~m ,rsoaa~iugs conmrd drugs through the ehain from stale-dating", the prevention of drug loss due to = airAden mw aewacdim aultodRadrons uroulhortrad dng nnvement ;n Om; to narm t theft, mislacementordama damage lin~aNd^,~v~em~'~wnat adminWra" ^ "g p ~
Alertstordrugeapproaching p g Pauent drug Nsi v, dng regimen patienl administratbn =state date'/support to environmental overstress. Prevention of drug loss Zone boundadm peffWed mo~errterdt wuSe Prot ecdngdNgstrom P~vemsew~dNg m ent, theft ar being due to theft, misplacement or damage due to `a.~,~c+-dNg tras~d ~õ
environmental overstress must be com lemented En"r ryean' e~,oaed to harmful p = Dnrg mrt i and wcason envvonmental conditions = Support for validated saFe by allowing for legitimate movement around the = DruglD(RFlD) onwtortetoreadminleterirg _ drug inventory = Drtg bcpion (by RFiD reader acetion Enablin ) 9 ry paftnq hospital, as well as legitimate authorized clinician Padwgaedn,gquarmnein s^re3.oncedcaF1132. aetiviees access.ln articularthereneedstobecontinuous -s s~e~aiidated P oosslob ma~wuai drug paarage enwraMnen<- q uf>~re monitoring of the location of expensive, limited RFro sensors admirmstrat+on procedures access medications and dnigs and narcotic drugs which are high risk targets for crime, as well as environmental monitonng of environmentally sensitive drugs.
The key attributes of this application are: -a) Low latency - 21 a. Drug administration support must be rapid since the clinician will be awaiting confirmations at key steps of the process for each patient drug administration b. Dnig misplacement needs to be corrected before third party finds drugs, c. Environmental stress needs to be detected and corrected before drug is damaged (E.G. drug cart location and thermal/sun loading environment and other environmental parameters tracked) d. Drug theft needs to be detected and stopped before theft is completed (EG.
Thief stopped before exiting pharmacy or exiting building) b) Security - Drug whereabouts and inventory data must be protected, unauthorized third party access not allowed, or must yield useless data, while authorized access must yield accurate data, including at the scanning primitives level c) Dependability - Drug mis-identification can lead to ADR's so type identification must be accurate or supported by human visual [
confirmation, itself an error-prone process. Inventory requires accurate counting and type identification d) Different drugs have different environmental limits and shelf lives so accurate drug identification important to maintaining environmental safety and to minimize expired life product Hence the value of this solution is that material and inventory tracking and protection can protect the drug supply while controlled and validated drug administration to patients in a closed loop system has been projected to massively reduce ADE's, and to save lives. It allows for the prevention or at least minimization of loss of drugs due to theft, mispiacement, damage as well as a real time ability to locate and track drug carts, major drugs in hospital as well as an ability to monitor and potentially control access to restricted access drugs The inputs, outputs and functions for this service are given in the Figure The primary ECAS contributors and enablers are: -a) Providing a real-time view of the whereabouts and contents of the hospital drug inventory by tracking hierarchical packaging at box, container, drug cart level and potentially at the prepared patient dose level (for drug-patient administration purposes) b) Detecting, alerting unsafe conditions and practices c) Supporting safe validated drug administration d) Alerting potential drug misplacement, drug theft situafions Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (drug cart, major drug containers but not every single pill) b) Sensor (thermal, possibly iight/UV, possibly humidity/water) at the pharmacy, pharmacy storage shelf/closet/refrigerator/freezer level and on the drug carts within the rest of the hospital c) Identity via RFID scanner, itself being locatable d) Patient and administrator location, identity primitives Key Context parameters a) Drug type, value, b) Access restrictions, c) Required drug environment, d) Actual drug environment, e) Clinician drug rights and privileges, f) Drug location, g) Cart location, h) Proximate clinicians i) Patient drug administration schedule and history Code Brown - Wandering Patient Protection The objective of this application is to track the Service ice Example Code Brown - Wandering patient protection whereabouts of specific patients who are prone to wander and to alert staff rapidly enough to prevent the patient wandering into proscribed areas while allowing regular routine Inputs Functions hospital workflow activity. Location tracking FaciM1ty/clinlcal information Wandering patient protection Outputs hWspdaf grid map, no ~o zones - Processing of raw location data to aspects may be common with other activities caWcian iD'g, rweg, pm~ determine patlent location and =-?atient ID and assodated wandering proximity conditions or may be used "stand-alone . history - stabl sh , patient bcat on against = Tracking of patient = Alen response as function of naaae of E
"~pn allowed zones, conditional allowed location and associations The key attributes of this application are: Context zones and exclusion zones over stay in hospital = zone txwndedes of pe"m irced panent - Establish history of proximity =
Flagged alens for a) Low latency - System must track patient movememasfuntlionofprwimityelements eventsforeachproximty volationsofpoloyon = C6nidan tetminal type and connedrvAy combination pafieM location zones location and proximity to clinicians, map this csntaen mie bymne - Provide escaiatin flags based on versus proxim7ties to zones rapidly and accurately enough that Envi~ronen'~ment "~~ aeasnaap or"~fas nature ofviolationsinarapid atient movement wanderin ~nician ~an n"act rpdm~ag manner unauthorized P ( g) = watientiocation"ectorpdmitrves can be alerted before risk of injury jurY or data ( range, ID of panies detected) disturbance takes place b) Security - Lost/ wandering patient information should only go to those who "need to knovd"- certain clinicians and sometimes security c) Dependability - To avoid spurious alerts are the solution should (to a high degree of 22 confidence) a. flag a lone patient crossing into a no-go zone b. should not flag a patient who is in an OK zone near to a no-go zone but not vectored towards the no-go zone c. should not flag a patient who is in a conditional go-zone in the company of a clinician who has sufficient permissions to take the patient there Hence the value of this solution is that preventing patient wandering reduces patient loss/misplacement, reduces disruption to workflow due to need to divert resources to finding the patient and suspending treatments until patient is found, saves much angst, bad publicity, lawsuits. Preventing patients approaching unreasonable hazards (in context of patient facufties) reduces risk of patient accidental injury. Selectively notifying the nearest security personnel to event saves time and targeted communications to the appropriate clinical personnel and security personnel causes less disturbance to general hospital population The inputs, outputs and functions for this service are given in the Figure .
The primary ECAS contributors and enablers are: -a) Real time monitoring of patient location and analysis for threat conditions based on patient location, vector against approved, conditional go, no-go zones b) Threat conditions versus location are adapted by proximity of authenticated authorized clinicians (who may take the patient into zones that could otherwise not be visited) c) Rapid alerting to nearby clinicians and / or security staff dependent upon detected threat.
d) Patient heading to exterior door with no clinician in tracking proximity can trigger targeted highest possible security response Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (patient prone to wander) b) Location (clinicians) c) Location (approved visitor) d) Location (security personnel) e) Identity primitives for all of the above Key Context parameters a) Subject dynamic location, vector b) Hospital zones and permissions c) Location of proscribed zones, building and/or area entrances and exits d) Location of hazardous equipment e) Parameters associated with Patient ID
f) Associated clinician ID's g) Associated clinician duty shifts h) Associated visitor ID (e.g. son, daughter) i) Associated rights of h) Scenario Interdependencies For R3- Basic Equipment Tracking --------------- ------=---=--------- ;
~------- ----HIS ; HCIS Hosoital Clinical.
Facility Clinician Patient Patient Faeilitv. Staff and data data data Clinical data PatieMdatabases ~ '---------------------------------- ~ ' and infrastructure ----- ----------------------= -=------..-...-.

To client applications R3 - Equipment Basic tracking, location Environmental and condition Awareness 23 r+orca coõrmwa mr~,wm This shows the subset of functions from the chart on page 17 that are actually used for Basic Equipment Tracking R3-Equipment tracking, location, condition Walkthrough ____________________=-.-__ ag ___-=---. __-i: ----------------------------------------------------===-=---===-----------------Equipment E4uipment Sensors Basic TI conditionl location Location Sensor data environment receivers receiver system a) Receive equipment condition, a) Receive tocation, usage, environment primitives identity primitives ,.., b) Compute condition, _=--1 --=---== y ;;
b) Comp bounds environmeMusage location, iute eorrfirm spatial identH d. Oeyuipmant Condition, ti___________t __ con itions environment, . ote c) Compare against limits usage prior Prior -~ c) Com re wkh ~evious Environmentlimit ~/ meaeurements:
location lowtion, identity ~r equipment OK Not OK ~ Usage history 68SIC d) Establish vector Appropriate protocol tracking 1 " or policy applied -------................
Zone map ~ ef ~sfa7fisliTucabon, vecfor relative to Zone map Zone Zeoq ue b eseetd_~ 0 Apply Zone map based inQ
listard location policies mapp poliey OKf Not OK A& context __._._.w.W----__._.__i_______________ ProXimi Establish proximity to clinician ~ tnput from f(location, vector) clinician location i ~) Not proximate Proximate Theft protocol and Clinician/equipment protocol policy applied and policy applied -------------------------------------------------- ----------------- --------24 rrnd c~rmmnd `n~nm This shows the overall flow of activity for Equipment Tracking and Condition Monitoring - it includes a sensor component not shown in the previous figure Functional Interdependencies For Code Blue ----------------------------, ------------------------------------- -HIS HCI Hosokal Clinical.
Facility Clinician ; Patient Patient Facilitv. Staff and data data data ¾tinical data Patient databases L =----=----------- --- and infrastrudure R6 - Cliniwl 11 E1 - Code Bluelplnk - emergency collaboration cardiaclrespiratory event -adultlpediaftic I- =c == =
... =..= .... ....... ..5~' R5 - Clinician Point of Care ~"c ; R7 - Drug safety, communications ;
and .................... ..
.....................................................
security onvironmerk R4 - Equip4/ clinician, ciinicianl Location-woximitv patient or equip'tf patient association based association and sensor association R1 -Clinician R2 - Patient R3 - Equipment Basic e. r Basic coordinates location tracking andlor tracking, location layer a~ttt Environmenfal and context monitoring and condition st,ucturee Awareness 25 umd canw vw wna.oana, This shows the functional interdependencies for the Code Blue event, through two phases, being: -a) Adaptively forming the Code Blue team b) Providing support to the resuscitation treatment as an urgent, life-critical point-of-care activity with intense clinician collaboration once the team is formed (El) Code Blue team formation phase walkthrough Patient experiences LTE
First responder raises alarm First clinician declares "Code Blue" on terminai Clinician, patient ID, location determined by Code team skill ECAS Clinician requirements ~/ skills list List of candidate Blue team cliniclans established +-~ !
I Duty roster Clinician i location from Each class of physicians ECAS loration ~'- rank-ordered by proximity i CiiniciansI comacted Clinician accepts Clinician declines/
' does not respond Add to team, notify of 1 location Is there another clinician with Is team compiete? theselskills Y Yiqs ~o \, As per POC example + Go to that clinician Contingency plan (may equipment location example inciude re-contacting (for crash cart) clinicians) 26 rwn~ conn,anw inwni.rm This chart walks through the team formation phase.

{
Ik Quantitative Requirements Comparison Edriioment tradilna, ~.' Clinician PoiMof Care Coda Blue (E11- team CddeAdam (E2{
Ioeation and oondllfon IR21 Communioations (R5) forinfna nhase Geography Campus in-budding, one or a Campus Campus in-building, one Campus few buildirgs or a few buildings + 250 yards outdoors Scale 100's -10.000's, 100's to 1000's. 100's or patients, 100's of patients, 1000's per floor, 100's per floor, Combination of R2 and combination of 100's per AP 10's per AP R5 R2 and R5 Location precision Room, 3m Proximity or 20 cm Room, 3m Proximity or Room Room, outdoor for advanced applicatan 20 cm for advanced app's coverage Other sensors On medical e*pmerd No No (biohazards??) No (heat??) Volume of data Kb/s Mb/s Kbls Kb/s Message Latency Second Sub-second for theft Seconds (user Sub-seconds Seconds applications satisfaetion driven) AppAvailability" Medium - 0.99 to high 0.999 High-0.999 Very high-0.9999 High-0.999 Frequency Rou6ne-Iwndreds a day RoWine - continual 200 per year for 400 Rare-less than I
usage bed tertiary care par year hospital Criticality Moderate (for efficiency) Moderate (for efficiency) Mqsion-critical High Mobile devices Tag Phone with graphic Phone wfth graphic Phone wRh display, Tables, PDA's display, Tables, PDA's graphic display for EHR

Inftq'view -sa^oM,tnpwk.n Mtonwet-nwynoeatrxe-"rca Moststringentrequirernent 27 ran.[cmr~x,er This chart, split between pages 27, 28 shows the quantitative requirements that must be met to support four very diverse applications, each of which in its own way will stress the system.

Cp ts Quantitative Requirements Comparison (Cont.) Eauiomanttraclclna. Clinidan Point of Care Code blue (Etl Code Adam (EYl --IQ~tion and eondition (R21 Communicatibns (R5) Privacy Minimal, For patient data in High Minimal- during incident Minimal-during monitoring apps incident Security (of Medium High Medium Low (due to application access) reMY) Audit(ng, logging Yes Yes -Efflciency, Yes-detailed (?) Yes (if required) malpractice Hospital may not want Mobile Device 6 months m(nimum (Tags) I day (shift plus personal 1 shi@ I
shifl Battery time when on call) 6 months min (tags) 6 mo min (tags) 6montha min (Tags) Data Location - periodic pirgs Voice Voice / Audio Voice I Audio Characteristics Condition- low data rate Text, Image Text Text messages Video-cotlaboratlve. Location Location Operational data - graphic or d'agrasdc Web pages, e.g. EHR
web pages, low res video Location such as EKG
Web peges y Data Rate Kb/s Mb/s Kb/s Kb/s =Most stringent requirement Auditing & logging for clinical apps - required or not? (data useful, but may not be required by law and may create unwanted malpractice evidence) [

What is novel? Some candidates.......

> The application of Environment and context awareness to a communication system > The application of Environment and context awareness to a clinical communication system > The application of Environment and context awareness to a generic communication system capable of providing muftlple diverse applications and services > The application of Environment and context awareness to a generic ciinical communication system capable of providing multipie diverse appiications and services > The use of institutional context data combined with situational context data to modify, generate or prevent speciflc communications > The use of institutfonal context data combined with situationai context data to modify, generate or prevent specific rbmmunicaGons in a clinical environment > Modification of workflows to include the impacts of institutionai and situational context processing engines > Modification of clinical workfiows to include the impacts of institutional and situational context processing engines 29 N~ coõrd.w~r M~õm~

}
The above list pf For more information > See Applications and Solutions for Healthcare - Hospitals A Perspective on ECAS, Version 1.0, 20 Dec 2006 > This document was supplied with the disclosure form {
{

x .r , .. . .
. . ,' , . x.f .. ~ ..
_~.
- ..: . .
r..
~ 4 f . . ~'3.

. . . - . ~ ... _~am.
K
. ~"t. . .. f `
. : . oy . . . . .., . . , I ..ii , .. . . . . ,' ,. . . Y i . . .. . .. . . .. {, ~n Applications and Solutions for Healthcare -Hospitals A Perspective on ECAS

Version 1.0 Issue Date December 2006 Thrust Solutions Thrust Authors Alan Graves, Jeff Fitchett, Input Thomas Chmara, Guy Duxbury, Brian Vezza, John Watkins Distribution Healthcare Team Nortel Networks Confid ntial Copyright Nortel Networks 2006: This document is the property of Nortel Networks who own the copyright therein. The information in this document is given in confidence and without the written consent of Nortel Networks given by contract or otherwise the document must not be copied reprinted or reproduced in any material form either wholly or in part nor must the contents of the document or any method or technique available there from be disclosed to any third party.

Nortel Confidential 1 of 226 Versions Draft 0.1 11-22-06 Draft 0.2 11-23-06 Draft 0.3 11-24-06 Draft 0.4 11-24-06 Draft 0.5 11-24-06 Draft 0.6 11-26-06 Draft 0.7 11-27-06 Draft 0.8 11-29-06 Draft 0.9 11-29-06 Draft 0.10 12-01-06 Draft 0.11 12-03-06 Draft 0.12 12-06-06 Draft 0.13 12-07-06 Draft 0.14 12-08-06 Draft 0.15 12-08-06 Draft 0.16 12-12-06 Draft 0.17 12-13-06 Draft 0.18 12-15-06 Draft 0.19 12-18-06 Version 1.0 12-20-06 Nortel Confidential 2 of 226 Executive Summary Healthcare and advanced Healthcare IT is an area of significant interest to Nortel since it is a significant and relevant business area that is in a state of flux, which is allowing new ideas and new players with new solution capability to come to the forefront.
Healthcare requires quality solutions with the quality Nortel has been known for and represents a large and growing market in the US and globally.

Various teams in Nortel recognized this situation in 2002 and have been driving towards a Healthcare Solutions business which is now becoming a reality. Part of the team promoting this direction has been based in the CTO office and has run an ongoing Healthcare Solutions program.

Previous work within the ATR organization within the CTO office has shown how advanced functionality can be added to our existing portfolio to create market-leading solution opportunities. Much of this work has been done in close collaboration with the Healthcare Vertical Marketing team and the results have been showcased successfully at the Nortel booth at the HIMSS 2004, 2005 and 2006 conference exhibition.

This report extends earlier reports (listed in the bibliography attached to this report) by moving beyond high quality "Clinical Grade" conventional solutions which addresses fully satisfactory "fit-for-use" solutions. The current enhancements described in this document move beyond a conventional solution and towards a fully workflow-integrated set of smart and anticipatory solutions. This is expected to lead to improved user-acceptance, in this case by clinicians fully embracing the solutions and modifying or even reinventing their workflows to exploit the new capabilities.

This is achieved by the introduction of the concept of an Environment and Context Aware Solution, whereby the communications network (in this case a clinical communications network) is given enough intelligence and access to information from configuration servers, policy servers, user lists and profiles, facility information and roles information that it can make significant and useful decisions about the context (aka situation) surrounding the communication and can adapt or optimize the communication as a result. This may mean preferentially feeding appropriate information to an authenticated user, preventing communication to an inappropriate user, adapting communications to the circumstances of the user or the user equipment, or even establishing machine to machine communication with unattended equipment, etc.
This is further enhanced by adding environmental awareness, either with location/proximity sensing technology, or other forms of environmental sensors (e.g. optical, thennal, video, pressure, gas, toxin and biotoxin, vibration/movement, acoustic and other types) or both location and other sensors. These enhancements permit services to be provided that adapt to the actual communications needs of legitimate users in the context of both their environment and their workflow situation. A high level view of an ECAS
solution is given in Figure 0.1.

Nortel Confidential 3 of 226 Figure 0-1 Basic Structure Of An Environment/Context Aware Solution The relationship between a conventional solution, a Clinical Grade solution and an ECAS
(Environment and Context Aware Solution) is shown in Figure 0-2.

The basis for the lower upward spiral in Solution Capabilities and user acceptance is the application of Clinical grade performance goals leading to solutions that fully meet the specific requirements for critical clinical systems instead of more or less (often less...) approximating meeting those needs.

The basis for the upper upward spiral of Figure 0-2 is the use of context-responsive systems, coupled with environmental awareness. These Smart systems enable enhanced convenience features for the end user clinician community; enhanced, more information-rich and more productive clinical workflows; as well as increased clinical safety and both information and physical security. As such they will strongly encourage the adoption of advanced solutions into healthcare IT and clinical processes but must meet the same high quality as the base Clinical Grade communications. This requires that ECAS
must remain based upon the Clinical Grade attributes that allowed the first (lower) upward spiral.

In practice the two spirals do interact somewhat since achieving Clinical Grade performance is facilitated by ECAS attributes but the ECAS implementation must meet Clinical Grade requirements in several areas, including dependability, security, ubiquity of coverage, etc.

Nortel Confidential 4 of 226 ___ -----~
" ' ECAS - workflow N Q 7i _ _ _ _ _ - impacting solutions cm - '- spiral > a~ __------m t~a Clinical Grade Application, Users - - - - - - - -networks - network and Workflow _ _ _ _ - - - -- fitness for use spiral Dependable, secure, IT Servicesto support pervasive, dimensioned and enable the infrastructure applications > Solutions have to be driven by understanding end user workflow, and how we can impact those applications > A positive upward spiral can be generated by evolving suitable grade solutions (Clinical Grade, etc.) and then evolving beyond these > An innovative evolution is the application of ECAS, providing radical new capabilities Figure 0-2 ECAS - It's About Solutions That Work For The Users To this end we are working towards a Clinical Grade Environment and Context Aware Solution, which consists of context aware solutions (smart systems that understand the context around what they are being asked to do and which can adapt their behaviour to match a set of policies and protocols surrounding the communications environment), coupled to an environmental awareness provided by both families of sensor technology and by the use of various location and proximity technologies, both of which allow the smart system to become aware of the physical environment in which it operates as well as the policy/permissions/ authentication/privileges, protocols that it can access from servers and databases.

This has been studied in the context of applying ECAS into several general clinical practices at medium sized hospitals and in particular to a set of hospital clinical and non-clinical or operational processes, spanning routine day-to-day operation and emergency response situations to look towards calibrating an ECAS solution for a medium sized hospital.

This work will support the future vision-forming and direction-setting for the Healthcare Solutions business and will also set the direction for aspects of a major external university research program, through the establishing of a new Research Network.

The work reported on here is a start - it shows a vision and a comprehensive solution.
Work remains to be carried out on partitioning the vision and overall solution into several economically, technically and functionally viable steps to provide a road map for a roll-out, although preliminary investigations indicate that this will not present a problem.
Furthermore, while this work has been carried out based upon the best clinical input we have received over the last three years, much work remains to validate the clinical assumptions contained herein with the clinical community, which will be done as part of the Healthcare UI program in 2007-2008.

Nortel Confidential 5 of 226 If we achieve the results we expect then ECAS in Healthcare can both be an instrument for clinical change and can position Nortel as a thought-leader in Healthcare Information Solutions.

In order to achieve this situation Section 10 of this document sets out a series of next steps for Nortel to take at the business unit level, especially at the Healthcare Solutions level, at the CTO/ATR research and exploratory level and areas where Nortel can beneficially support and encourage academic research.

At this time an aggressive and substantial program of academic research is under discussion with several parties, notably three Associate Deans of Research and the current ad hoc academic programs are being marshaled into a Research Network (an academic network of research collaborators across several disciplines in several universities) thrust for substantial government funding.

Nortel Confidential 6 of 226 Applications and Solutions for Healthcare Applications - Hospitals A Perspective on ECAS

Executive Summary 3 Figures 13 Tables 15 1 Introduction 17 2 The current situation 21 2.1 Pressures For Change, Methods Of Change 22 2.2 Healthcare and IT 23 2.2.1 Hospital - Radiology and Picture Archiving and Communication System (PACS) database solutions. 25 2.2.2 Hospital - Point-of-Care (PoC) communications 26 2.2.3 Hospital - PoC/PES 26 2.2.4 Hospital - Workflow-engaged solutions 27 2.2.5 Hospital - Security, location and authentication solutions 27 2.2.6 Hospital - Various emergency response systems 27 2.2.7 First responders -wide area secure mobility 28 2.2.8 Clinics and physician's offices- SMB high performance solutions 28 2.2.9 Hospital groups and all other clinical information users - data centers with high quality BC/DR solutions 28 2.2.10 Patient Involvement and Home Health- appropriate telehealth solutions 2.2.11 Mobile clinicians - wide area secure mobility solutions 29 2.3 Clinical Grade 31 2.4 A Modern Pre-ECAS Hospital Information System 32 2.5 Clinical Scope To Be Addressed 34 3 What ECAS Capabilities Can Do 35 3.1 Building blocks of ECAS 36 3.1.1 Environmentally Aware System 36 3.1.2 Context - Responsive Solutions 37 3.1.3 Context - Responsive & Environment Aware Solutions 37 3.2 ECAS Attributes 38 3.2.1 The need for smart communications 38 3.2.2 Environmental Awareness 39 3.2.3 Factors determining context 40 3.2.4 Context decisions 40 3.2.5 Bringing environment and context together 41 3.2.6 ECAS and Clinical Grade 42 3.2.6.1 Availability 43 3.2.6.2 Security 43 3.2.6.3 Quality of Service (QoS) & guaranteed Service Level Agreements (SLA) 3.2.6.4 Pervasive Coverage of the Facility and beyond 45 3.2.6.5 Seamless mobility with session adaptation 45 3.2.6.6 Transaction integrity 47 3.2.6.7 Non-repudiation 47 3.2.6.8 Provides ability to evolve - "future-proof' 48 Nortel Confidential 7 of 226 3.2.6.9 Human-system interactions - ease and consistency 48 3.2.6.10 Workflow Integration 49 4 Generic Clinical Infrastructure Solutions for ECAS 51 4.1 Application-specific versus generic infrastructure 51 4.2 ECAS as a Generic Infrastructure 51 4.3 Distributed, centralized context processing 54 4.4 Sensor solutions 54 4.4.1.1 Sensor Access Networks 55 4.4.1.2 Sensor networking and conversion of data to information 56 4.4.1.3 Value of multiple senses 56 4.5 Functional requirements and impact on solution selection 57 4.5.1 Common Functional Infrastructure 57 4.5.2 Agility in Information Infrastructure and Workflow 57 4.5.3 Clinical Grade impacts 58 4.6 Fitness-for-use requirements and impact on solution selection 59 Solution composition 61 5.1 Component parts 61 5.2 Network Infrastructure 62 5.2.1 Communications Infrastructure 62 5.2.2 Hospital Access Network 64 5.2.3 Wireless and WLAN 65 5.3 Physical Inputs 65 5.3.1 Location technologies, precision, accuracy and ubiquity 65 5.3.2 Sensors and sensor networking 68 5.3.2.1 Sensors 68 5.3.2.2 Sensor Networking 69 5.3.2.3 Geographically Distributed Sensor Networks 75 5.4 Communications Status 76 5.5 Entity Status 77 5.6 Control architecture 77 5.7 Security and authentication architecture impact 82 5.8 Context processing structures 82 6 The nature of healthcare applications 85 6.1 Hospitals, clinics, mobile clinician, home healthcare 86 6.2 Mobility 87 6.3 Routine, Emergency 89 6.3.1 Characteristics of Routine Events 89 6.3.2 Characteristics of Emergency events 89 6.4 Clinical involvement 91 6.4.1 Independent of clinical practice 91 6.4.2 Linked to clinical practice 91 6.4.3 Clinically engaged 91 Nortel Confidential 8 of 226 6.4.4 Clinically enabling 92 6.5 Clinical Applications 92 7 Application Of ECAS To Healthcare 95 7.1 Some major routine application areas - end user perspective 98 7.1.1 Clinician Coordinates Location And Context 98 7.1.2 Patient Tracking And/Or Monitoring 98 7.1.3 Equipment Tracking, Location And Condition 98 7.1.4 Equipment/Clinician Or Equipment/Patient Association 99 7.1.5 Clinician Point Of Care Communications 99 7.1.6 Clinical Collaboration 99 7.1.7 Drug Safety, Security And Environment 99 7.1.8 Various Applications In Support Areas 100 7.1.9 Routine equipment and terminal calibration, maintenance and verification 7.2 Some Major Emergency Application Areas - end user perspective 100 7.2.1 Emergency (E)"Code" - Various Emergency Codes 100 7.2.1.1 Code Blue/Pink - Emergency Cardiac/Respiratory Event - Adult/Pediatric 7.2.1.2 Code Adam - Missing Infant Or Child 101 7.2.1.3 Code Brown - Wandering Patient Protection 101 7.2.1.4 Code Yellow - Disaster Response 102 7.2.1.5 Code Red - Fire 102 7.2.1.6 Code Orange - Hazardous Material 102 7.2.2 Drug Theft Or Tampering Detection 102 7.2.3 Equipment Theft Or Movement Outside Of Authorized Zone - Detection 103 7.3 Clinical Communications And Support Services Relationships 103 7.4 Basic Functionality and Performance Requirements For Selected Application Areas 107 7.4.1 Results Overview- Requirements From First Level Of Drill Down 108 7.4.2 Detailed Requirements from Drill Down 108 7.5 Modularity and Complexity 110 8 An Implementation Case Study Covering Physical Infrastructure For A Mid-sized Hospital l1l 8.1 Basic infrastructure - Pre-ECAS 111 8.2 Basic Infrastructure-Post ECAS 112 8.3 Solution overview 113 8.3.1 Solution Overview- Pre ECAS 113 8.3.2 Solution Overview- Post ECAS 115 8.4 Numerical model 121 8.5 ECAS Solution Roll-Out Example 123 8.6 Issues and areas for investigation 126 9 Extending solutions to other sites 129 9.1 Large hospitals, small hospitals 129 9.2 Reaching out to the clinic and physician office 129 9.3 The mobile clinician 130 Nortel Confidential 9 of 226 9.4 Home healthcare applications and solutions 130 Next Steps 133 11 Glossary 139 12 Bibliography 143 13 References 145 14 Appendix - Basic Functions and Requirements For Selected Major Routine Application Areas 147 14.1 Clinician Coordinates Location And Context 147 14.2 Patient Tracking And/Or Monitoring 150 14.3 Equipment Tracking, Location And Condition 152 14.4 Equipment/Clinician Or Equipment/Patient Association 155 14.5 Clinician Point Of Care Communications 157 14.6 Clinical Collaboration 159 14.7 Drug Safety, Security And Environment 161 14.8 Various Applications In Support Areas 164 14.9 Routine equipment and terminal calibration, maintenance and verification -Appendix - Basic Functions and Requirements For Selected Major Emergency Application Areas 165 15.1 Emergency (E) "Code" - Various Emergency Codes 165 15.2 Code Blue/Pink - Emergency Cardiac/Respiratory Event - Adult/Pediatric _ 15.3 Code Adam - Missing Infant Or Child 168 15.4 Code Brown - Wandering Patient Protection 170 15.5 Code Yellow - Disaster Response 172 15.6 Code Red - Fire 175 15.7 Code Orange - Hazardous Material 178 15.8 Drug Theft Or Tampering Detection 180 15.9 Equipment Theft Or Movement Outside Of Authorized Zone - Detection _ 183 16 Appendix - Detailed Drill Down On Selected Application Areas 187 16.1 R3-Equipment tracking, location, condition 188 16.1.1 Requirements - qualitative and quantitative 190 16.2 Application #2 R5-Clinician Point of Care Communications 194 16.2.1 Qualitative and Quantitative Requirements For A Point of care Solution 16.3 An Example Point of Care Application Scenario Using ECAS 197 16.3.1 Perspective # 1 - External Observer view of example walkthrough 197 16.3.2 Physician Operation during Example - Walkthrough - with ECAS 198 16.3.3 ECAS-based PoC System Operation during Example - Walkthrough 199 Nortel Confidential 10 of 226 16.4 Application #3 El-Code Blue/Pink- emergency cardiac/ respiratory event -adult/pediatric 205 16.4.1 Code Blue (E1) - Qualitative & Quantitative Requirements 205 16.5 Detailed Requirements from Drill Down 209 17 Appendix 2 Numerical Strawman And Reference Hospital Model 211 17.1 Hospital Model 211 17.1.1 Staff Attributes 211 17.1.2 Staff Time Distribution 212 17.2 Layout 213 17.2.1 Physician Specialties 216 17.2.2 Staff Availability versus Location 217 17.3 Hospital Model Applied to Code Call Scenario 217 17.3.1 Information Required for Code Call System 218 17.3.2 Number of Code Calls 219 18 Appendix 2 221 18.1 Emergency Codes and MET Protocols 221 18.1.1 Response Guide - Ohio Health 221 18.2 Emergency Codes and Protocols for Duke Memorial 225 18.3 EMTALA Requirements 226 Nortel Confidential 11 of 226 Figures Figure 2-1 Healthcare as Specific Communications Networks ........................................ 24 Figure 2-2 Healthcare As A Communications Network ................................................... 30 Figure 2-3 Hospital Information System - Wired & WLAN POC
................................... 33 Figure 3-1 Basic Structure Of An Environment/Context Aware Solution ....................... 36 Figure 4-1 ECAS solution for healthcare, using templates .............................................. 52 Figure 4-2 Geospatial ECAS template .............................................................................

Figure 4-3 What can be sensed?
...............................................................................
....... 55 Figure 4-4 Value of multiple senses .
...............................................................................

Figure 5-1 Hospital access network showing possible ECAS components ..................... 65 Figure 5-2 Location and proximity tags ........................................................................... 67 Figure 5-3 Sensor network architecture - simplified view .............................................. 69 Figure 5-4 Layered view of hospital ECAS architecture ................................................. 71 Figure 5-5 Hospital reference model with ECAS system ................................................ 74 Figure 5-6 Mapping of ECAS onto Nortel's reference architecture ................................ 75 Figure 5-7 Network dimensioning varies with application .............................................. 76 Figure 5-8 Hierarchy of ECAS control structures for healthcare .
................................... 78 Figure 5-9 The OODA loop ...............................................................................
.............. 79 Figure 5-10 Policy injection in the OODA loop and ECAS architecture ......................... 80 Figure 5-11 The OODA loop and ECAS architectural components ................................. 81 Figure 5-12 Details of architectural components in OODA .
............................................ 81 Figure 5-13. System Data Model. Elements were added in the ECAS Template pattern to handle real time communications/collaboration .
.......................................................... 83 Figure 6-1 Some Example ECAS Healthcare Application Areas ..................................... 87 Figure 7-1 Scenario Interdependencies- high level .......................................................... 96 Figure 7-2 Scenario Interdependencies- For Groups of Service Types ......................... 104 Figure 7-3 Scenario Interdependencies - For a wide range of example clinical, non-clinical and emergency services ...............................................................................
....... 105 Figure 7-4 Scenario Interdependencies - For a wide range of clinical, non-clinical and emergency services ...............................................................................
.......................... 107 Figure 8-1 Wired & WLAN Point of Care Solution ...................................................... 111 Figure 8-2 Wired & WLAN Point of Care Solution With ECAS
................................... 112 Figure 8-3 Example Pre-ECAS Hospital Infrastructure ................................................. 114 Figure 8-4 Example ECAS Hospital Infrastructure ........................................................ 116 Figure 8-5 Possible layout of Receiver Nodes for a Floor-Wide UWB Location System -First Floor ...............................................................................
......................................... 117 Figure 8-6 Possible layout of Receiver Nodes for a Floor-Wide UWB Location System -Second Floor ...............................................................................
.................................... 117 Figure 8-7 Approximate fire sensor locations -hypothetical model hospital ................. 120 Figure 8-8 Approximate numerical dimensioning of hypothetical hospital ................... 122 Figure 8-9 Example ECAS Hospital Infrastructure - Pre-ECAS
................................... 123 Figure 8-10 Example ECAS Hospital Infrastructure - WLAN Location integrated into Non-Clinical Services ...............................................................................
...................... 124 Nortel Confidential 13 of 226 Figure 8-11 Example ECAS Hospital Infrastructure - WLAN location integrated into non-clinical and selected clinical services ...................................................................... 124 Figure 8-12 Example ECAS Hospital Infrastructure- Substitution of UWB
location.... 125 Figure 8-13 Example ECAS Hospital Infrastructure - Full suite of Location -Aware functions ...............................................................................
........................................... 125 Figure 8-14 Example ECAS Hospital Infrastructure -adding the sensor-based senses. 126 Figure 14-1 Clinician coordinates location (R1) ............................................................ 149 Figure 14-2 Patient tracking and/or monitoring (R2) .................................................... 151 Figure 14-3 Equipment tracking, location, condition (R3) ............................................. 154 Figure 14-4 Equipment / clinician / patient association (R4) ........................................ 156 Figure 14-5 Clinician Point of Care Communications (R5) .......................................... 158 Figure 14-6 Clinical Collaboration (R6) ......................................................................... 160 Figure 14-7 Drug safety, security and environment (R7) ............................................... 163 Figure 15-1 Code Blue - emergency cardiac/ respiratory event - adult (E1) ................. 167 Figure 15-2 "Code Adam"- Newborn/infant abduction response (E2) ......................... 169 Figure 15-3 Code Brown - Wandering patient protection (E3) ...................................... 171 Figure 15-4 Code Yellow - Disaster Response (E5) ..................................................... 174 Figure 15-5 Code Red - Fire (E6) ...............................................................................
.... 176 Figure 15-6 Code Orange - Hazardous Material Release (E7) ..................................... 179 Figure 15-7 Drug theft, damage or tampering detection (E8) ....................................... 182 Figure 15-8 Equipment theft or movement outside of authorized zone (E9) ................ 184 Figure 16-1 Scenario Interdependencies for detailed drill downs ................................. 187 Figure 16-2 Scenario Interdependencies For R3- Basic Equipment Tracking ............... 193 Figure 16-3 R3-Equipment tracking, location, condition Walkthrough ......................... 193 Figure 16-4 Walkthrough on Hospital System - with ECAS - 1 .................................... 202 Figure 16-5 Walkthrough on Hospital System - With ECAS- 2 .................................... 203 Figure 16-6 Walkthrough on Hospital System - With ECAS - 3 ................................. 203 Figure 16-7 Walkthrough on Hospital System - With ECAS - 4 .................................. 204 Figure 16-8 Scenario Interdependencies For Point of Care Communications ............... 204 Figure 16-9 (E1) Code Blue team formation phase walkthrough ................................... 207 Figure 16-10 Scenario Interdependencies For Code Blue ............................................. 209 Figure 17-1 Staff distribution (ad hoc estimate) ............................................................ 212 Figure 17-2 Antelope Valley hospital campus ............................................................... 213 Figure 17-3 Antelope Valley Hospital ...........................................................................

Figure 17-4 Abstraction of hospital layout .
................................................................... 215 Figure 17-5 Hospital zones square footage .................................................................... 216 Figure 17-6 Code call system model .
............................................................................

Figure 17-7 Code call distribution (ad hoc estimate) ..................................................... 219 Figure 18-1 Response to code call, including student nurse .......................................... 225 Nortel Confidential 14 of 226 Tables Table 6-1 Generic Mobility Requirements For Classes Of Clinicians ............................. 88 Table 6-2 Ohio Emergency Codes ...............................................................................
..... 90 Table 7-1 R3-Equipment tracking, location, condition requirements from selected clinical, non-clinical applications ...............................................................................
.................. 108 Table 7-2 Quantitative Requirements Comparison ......................................................... 109 Table 15-1 Various emergency codes and ECAS implications ...................................... 165 Table 16-1 R3-Equipment tracking, location, condition ............................................... 192 Table 16-2 Quantitative Requirements Comparison ...................................................... 210 Nortel Confidential 15 of 226 Applications and Solutions for Healthcare Applications -Hospitals A Perspective on ECAS

1 Introduction Healthcare and particularly healthcare information technology (IT) is undergoing radical changes as finally, decades after some other market segments, clinicians are considering and adopting modern information access and management technologies into their workflows, albeit very cautiously.

This change opens up substantial opportunities for companies such as Nortel, especially those which can understand the special "mission-critical" nature of healthcare clinical IT
and are willing to partner with clinicians to understand their problems and produce appropriate solutions. This was recognized within the Advanced Technology Research (ATR) community in 2002 and programs were put in place to build expertise in this area.
This has led to a number of successes including Nortel's engagements at the annual HIMSS conference in 2004, 5 and 6, a filed-IPR portfolio and a number of previously published documents and publications, which are listed in the bibliography section of this document.

This document continues the process of looking for innovative healthcare IT
and Communications solutions by analyzing and understanding the needs of clinicians and clinical/non-clinical processes within hospitals, whilst also seeking to apply novel technology, communications and IT solutions to these needs and processes. The solutions being applied here are based upon the concept of an Environment and Context Aware Solution (ECAS), which is a smart communication network which can understand the physical environment it is being used in as well as the context surrounding the communications it is requested to carry out, also described as the communications situation. It achieves this by sensing, detecting or deducing key relevant parameters and then selectively and appropriately applying pre-determined policies, permissions, authentications, resource maps and lists, etc. to these, reaching conclusions and changing its behaviour based on those conclusions.

ECAS has multiple applications both inside and outside of healthcare and has been studied in 2006 in the context of healthcare, as well as in disaster response-workflow collaboration, where a major publication is being prepared coincident in time with this document. The project has also taken a brief look at the retail segment. ECAS
grew as a concept out of the 2005 Environmentally Aware Networks (EAN) program which had examined environmentally aware networks in healthcare, seaports (Port Authority of New York and New Jersey (PANYNJ) and Halifax, Nova Scotia) and a major municipal transit system (New York Metropolitan Transit Authority).

Nortel Confidential 17 of 226 This document touches upon the healthcare situation and explores the basic functionality and architecture of ECAS solutions (albeit not to the depth of some companion work listed in the bibliography) before exploring in depth a series of healthcare-related scenarios and applications. These applications cover a range from a basic non-clinical support function that could be used by a clinical or non-clinical application, through mainstream high volume clinical workflow applications, clinical emergency team forming as well as non clinical but patient-related emergency situation management.
From this work the basic qualitative and quantitative requirements for multi-functional solutions are established, along with the relationships between the various applications and services analyzed (a wide range of applications but not a complete set by any means).
These solutions are complex, but much of that complexity will have to be in place already in order to deliver today's capabilities, before ECAS is overlaid. Furthermore component parts of ECAS can be introduced sequentially in a phased roll-out, initially with a subset of the final suite of benefits and capabilities.

ECAS can be applied in multiple segments of the information flow within almost any area of Healthcare. In order to move forward with the available project resources we have had to reduce the breadth of scope of coverage to a specific healthcare sub-sector. This iteration of the document focuses on the applications and infrastructure in the general areas of a medium-sized hospital, leaving work on large and small hospitals, home healthcare, clinics/Medical Dental Buildings (MDB) as well as First Responders, etc. for future work. This allows us to do a more comprehensive exploration of that single Healthcare segment - medium hospitals, from which we can expand our work in future.
This document covers the basic ECAS attributes, potential clinical applications in the general areas of a medium-sized hospital, not covering the workflows in the Operating Room (OR) or Radiology (which has been covered elsewhere- Ref 6). Whilst this document does not fully disclose a form of roll-out, but rather focuses on the end-solution, it is recognized that a staged, phased roll-out of capabilities in several steps, each step being financially, functionally and technically viable, is crucial to achieving an ECAS roll-out as envisaged here for a medium hospital setting. This is recommended to be addressed as a priority area in 2007.

This solutions work can in future be used to lead to more refined detailed requirements, workflows and solutions but at this time just a preliminary view of the nature of the overall joint solution is presented. To take this further requires a program of work both engaging the clinical community and applying innovative engineering. It is anticipated that this may form part of a major new multi-university thrust now under definition.

If this work is successful it will allow Nortel to be projected as s healthcare solutions leader as well as adding to the number of IPR filings in the healthcare solutions space. In addition this work will support the new Healthcare Solutions business team and will provide concepts, solutions, technology directions and IPR germane to their future business.

Nortel Confidential 18 of 226 Furthermore it is anticipated that opportunities will arise for Nortel in the areas of: -a) Increased solutions business opportunities as a perceived solution leader in healthcare b) Substantial ability to migrate to a solutions model for business c) Ongoing and reinforced opportunities for Nortel products as part of the solutions a. Multimedia communications products b. Physical layer products c. Solutions, servers and server software products These areas and opportunities will be enhanced if Nortel can establish additional channels-to-market.

Currently the primary solution/software beneficiaries of the ongoing changes in healthcare are the Healthcare Systems integration companies, such as McKesson, Cerner, Epic, Misys and even GE (for radiology). Major software companies such as Microsoft are also attempting to establish a major presence in this area.

While Nortel neither has the expertise or the resources or the channels-to-market to successfully compete in these companies head to head, they are each highly dependent upon a dependable capable infrastructure to best deliver their products' capabilities. ECAS may holds the key to providing such an advance in network and communications solution behaviour that it would provide seriously tantalizing opportunities to partner with some of these companies to share in their success.

Nortel Confidential 19 of 226 2 The current situation Healthcare is one of the most significant sectors of the economies of most developed countries and represents one of the most urgent challenges facing many countries. This is driven by the fact that not only is healthcare a significant part of most countries' GDP; it is also a growing expense, increasing at a rate far beyond the growth rate of most economies. For instance in the USA the overall healthcare system which 5 years ago represented 13.5% of the US GDP now accounts for around 16% of the country's GDP.
In Canada it is up from a low around 8.5% to more than 10% and it is approaching 10%
in the UK. The decrease in affordability is having dire impacts for some, with more and more Americans becoming uninsured, more and more US employers finding the cost of healthcare insurance makes them non- competitive. Government-run systems in many countries are consuming too great a percentage of available revenues, forcing those governments to ration or slow down the availability of some treatments or even not provide some of the more expensive treatments.

These healthcare systems are massive, the US system having nearly 1,000,000 hospital bed spaces in 5,800 hospitals, supported by 300,000 other healthcare facilities, mainly doctor's offices, dentist's offices, walk-in clinics and the like. The core US
healthcare workforce comprises 770,000 physicians and 2,700,000 nurses as well as many other healthcare professionals and workers and one in 11 employees in the USA work directly or indirectly in Healthcare. Other countries have similar systems scaled more or less proportionally to their population size.

These systems treat a very large number of people annually. For instance the US system sees 35,000,000 hospitalizations annually, or around 100,000 per day. But research (Ref 1) has also shown that they also do some harm - it is estimated that between 44,000 and 98,000 deaths occur annually in the US hospital system due at least partially to medical errors.

Furthermore 770,000 Adverse Drug Events (ADE's) are estimated to occur annually in US hospitals alone (Ref 2) and these are associated with about 7,000 of the medical errors causing death. An ADE is an event severe enough that some form of medical intervention is required as a result of a drug application to a patient -usually in error in some manner (wrong patient, wrong drug, wrong dose, wrong time, wrong treatment, lack of checking for a previously diagnosed and documented allergy - but not an undiagnosed or non-diagnosable medical allergy which, although it causes an ADE, the ADE is not as a result of a medical error).

Studies in other countries have found similar evidence for both medical errors causing death and for ADE's. For instance, when pro-rated for system size or population size the Canadian system sees proportionally more errors causing death (Ref 3).

Nortel Confidential 21 of 226 2.1 Pressures For Change, Methods Of Change All of this, plus several other stressors are fueling a need for change. These stressors include: -a) Aging population demographics, driven both by the aging of the baby-boomer generation and by the fact that medical advances allow a greater proportion of people to live to old age and hence be candidates for expensive-to-treat diseases of the elderly.

b) Improving treatments introducing more clinical capability, but often in the form of expensive complex treatments and procedures.

c) A critical shortage of both nurses and physicians, with many nurses and a lesser number of physicians leaving the profession due to long hours and high stress levels.

d) A heavy workload on the remaining staff to the point of affecting morale, and sometimes effectiveness.

e) Increased willingness by medical error survivors or relatives of victims to take legal action in medical error situations - this drives up malpractice insurance costs and makes clinicians risk-averse and conservative.

f) The sheer complexity of the clinical information that can be presented to a clinician using modem technology - the clinician can be overwhelmed by it.
This is compounded by a legal liability should the clinician not make use of appropriate and available information - a liability that does not exist if the information was not available.

g) The overall cost of health insurance, resulting in more uninsured people in some systems, and in the curtailing of healthcare services or the slow adoption of new services in other systems.

h) Increasing regulations as government bureaucracies struggle to respond to the situation and which end up exacerbating aspects of it.

i) An increased public expectation for the performance of the medical system under all conditions, irrespective of the severity of the condition, and an increased intolerance for the scientific, knowledge and human-based limitations of the healthcare system.

Fortunately there are some ways forward to improve the situation, to mitigate some of the problems or at least ameliorate their impacts. It is not the purpose of this document to delve deeply into all of the ways to improve the situation but a few areas where improvements can be made as a result of data, communications or information Nortel Confidential 22 of 226 technology application will be touched on, since these can open opportunities for Nortel to contribute to the improvement of the human condition as well as opening up valuable commercial opportunities.

The three areas that are valuable for us to examine are: -a) Improved and streamlined clinical processes and procedures, especially those enabled by communications technology b) Injecting IT and communications into clinical processes, both to render existing processes more efficient or effective and to allow their evolution towards new and better processes. This document will mainly address this aspect, since it represents the area of largest opportunity for Nortel solutions.

c) The reinforcing of "wellness" or "illness-avoidance" so that a simple lifestyle change or early detection of indicators for risk or early detection of a latent problem can allow for an easier intervention for a change of outcome without needing complex, expensive, invasive end-stage treatments. This combines public education with levels of automated ongoing monitoring, etc.

2.2 Healthcare and IT

Healthcare as a sector has used IT for years in back-office administration, billing and business functions but has generally been a laggard in deploying IT into its clinical workflow practices, which can be seen both as an advantage and as a problem.
It is an advantage because new infrastructures can now be built and there often isn't an established incumbent supplier for that part of the clinical infonnation network in that hospital, making it easier to "get in". However the lack of IT in this area is a problem in that an IT-centric work ethic and culture has to be bred within the clinician community.
This community has a cautious, conservative work ethic, as well as having a significant presence of mature professional individuals who are intolerant of disruption and who have learned from experience to be skeptical towards change.

However a radical change, gaining momentum rapidly during the 1998-2001 time frame is now introducing IT into clinical processes in many forms. Already results have been published at international conferences showing how IT can benefit the practice of healthcare. Information published at the annual HIMSS conference as long ago as 2003 has shown that the proper application of IT can lead to: -a) Clinical effectiveness and productivity gains across entire departments in the region of 23%. This was reported in a pilot trial in Queens Hospital, NY, at HIMSS 2003. See Ref 4a, b Nortel Confidential 23 of 226 b) Adverse drug events - a form of medical error - these can be reduced by about 80% by the application of electronic prescription and administration recording with a validation solution. See Ref 5.

c) Faster turnaround - with a less than 12 hour turnaround on a fully read and documented radiology imaging session being achieved in greater than 85% of instances instead of only 12% completing in 12 hours, with the other 88%
taking over 12 hours. This was reported in a pilot trial in Queens Hospital, NY, at HIMSS 2003.

d) Less wastage - with unreadable radiology images dropping from 15% to 3%.
Since an unreadable image event (due to wrong imaging site, wrong, incomplete or missing patient ID, wrong parameters set for imaging, etc.) requires a repeat of the imaging process to correct the error this is equivalent to a 12%
productivity improvement. This was reported in a pilot trial in Queens Hospital, NY, at HIMSS 2003.

It is the general recognition that IT can benefit clinical procedures themselves that is triggering a rapid modernization of hospital IT systems, which previously had been mainly used for non-clinical activities such as billing and scheduling, but not as part of the mission-critical clinical processes themselves.

Some of the areas for application of communications technology in the new world of healthcare are shown in Figure 2-1.

Figure 2-1 Healthcare as Specific Communications Networks Nortel Confidential 24 of 226 These include: -a) Hospital i. Radiology and Picture Archiving and Communication System (PACS) database solutions ii. Point-of-Care (PoC) communications including mobility solutions throughout the hospital iii. PoC/PES - combining Point of Care functionality and a Patient Entertainment System in a common bedside terminal.
iv. Workflow-engaged solutions v. Security, location and authentication solutions vi. Various emergency response systems with various levels of clinical involvement, and which often use a common infrastructure or even application as their routine counterparts b) First responders -wide area secure mobility c) Clinics and physician's offices - Small and Medium Business (SMB) high performance solutions d) Hospital groups and all other clinical information users with access to data centers with high quality Business Continuance/Disaster Recovery (BC/DR) solutions to ensure that clinical records cannot be lost or corrupted e) Patient Involvement and Home Health- appropriate telehealth solutions f) Mobile clinicians - wide area secure mobility solutions 2.2.1 Hospital - Radiology and Picture Archiving and Communication System (PACS) database solutions.

Radiology is involved with the interior imaging of the human body and in the past would be classified as "X-Ray Department". Modem Radiology has a slew of imaging technologies to allow the interior examination of the human body, including X-Ray, Magnetic Resonance Imaging (MRI), Computed Tomography (CT), Positron Emission Tomography (PET), etc. Many of these are primarily digital and the others are "going digital" generating data files in lieu of film-based images. These images have to be collected, stored, analyzed/viewed, annotated and archived/retrieved in a digital environment. These functions are performed by the Picture Archiving and Communication System (PACS) and this is one of the earliest applications of digital communications technology inside of clinical processes. Workflow analysis for this area has been carried out elsewhere in ATR in early 2006-see Ref 6. This document will concentrate on workflows within the general hospital.

Nortel Confidential 25 of 226 2.2.2 Hospital - Point-of-Care (PoC) communications A Point of Care (PoC) occurs wherever a clinician interacts with the patient's condition information during care. Commonly this occurs when the clinician is with the patient and is interacting directly with the patient, with the patient playing an active (e.g. in a consultation session with the patient) or a passive role (e.g. during examinations or tests or treatments where the patient may not even be conscious), but the patient does not have to be physically present at a PoC session. For instance the clinician may be interacting with other clinicians to reach a decision on how to proceed, although this scenario is sometimes referred to as a Point of Decision, rather than as a Point of Care.
Clinician collaboration usually takes place between clinicians of dissimilar standing, e.g. Family practitioner with consultant or physician with nurse and this is reinforced by physicians' billing policies at least in Canada and probably elsewhere.

Whether or not the distinction is made between PoC and PoD all communicating or collaborating sessions require the contributing clinicians to be appropriately aware of the patient's condition, background, prior and current treatments, treatment plan, drug regimen, etc, etc. This requires that they have access to the patient's information during the PoC encounter and furthermore that they contribute their advancement of the situation back into the patient information record or database. PoC communications support this capability by bringing required clinical data to the PoC as well as capturing the information, requests, decisions and instructions generated in the PoC
session. The PoC
communication solution has to allow for clinicians to be highly mobile since this is part of the fundamental nature of their role. It also has to be highly secure, only allowing access to appropriate personnel.

2.2.3 Hospital - PoC/PES

Point of Care/Patient Entertainment Systems (PoC/PES) provide clinicians with a secure bedside terminal connected to the hospital clinical information system for their use during a PoC encounter with a patient in a bed ward but also double up as a patient-viewable multi-media or video terminal when a clinician is not using the terminal for a PoC session.
The adoption of POC/PES in hospitals is limited and the technology has limited applications, for instance being geographically limited in its full applicability to those areas where both patient entertainment and PoC sessions are likely to occur.
It also requires the clinician to log on to a new terminal at each patient encounter, which can increase the authentication actions workload on the clinician. However it does allow a large, bright terminal to be used, which allows for more information display than does the screen of a small portable hand held device. As such it has a significant potential role to play in delivering clinical information, mainly in bed wards, but is not a universal solution across the entire facility.

Nortel Confidential 26 of 226 2.2.4 Hospital - Workflow-engaged solutions This is not a specific solution but rather a specific and increasingly required attribute of solutions in many parts of healthcare. As the information and communication technology evolves so it becomes more and more able to positively impact the clinical workflows by becoming integrated with those workflows. This is only possible if the attributes of the communications and information systems are such that they do not disrupt the improvements and do not impede the change to the new workflow, for instance by being undependable or difficult to use - for instance the steady stream of software patches and forced reboots we have come to expect as part of our daily lives cannot be allowed to happen in the middle of a critical lifesaving clinical event. Neither can healthcare tolerate poor system security since not only does this present risks of illicit or illegal access to data and resultant loss of privacy, but it also would represent a more serious threat to the patients well-being - that of data tampering or alteration. Whilst we focus on hospital workflow engaged solutions for this phase of the work there are opportunities for workflow engaged solutions in many parts of healthcare. These will be dealt with in later work and in the university program now under definition.

2.2.5 Hospital - Security, location and authentication solutions Patient-identifiable clinical data is amongst the most private and confidential data there is about a human being and strict safeguards as to its use and as to who may see and interact with it are set by both law and by codes of conduct. Hence modern clinical applications which make use of this information in any way have to be associated with a high degree of security, both to keep inappropriate viewers out and to protect the integrity of the data, since tampered data is not dependable data. This requires that clinicians only be granted access to the data once they have been positively identified and their personal rights profile has been compared with the request they have made. This multi-step process provides for user authentication, and authorization. In future it is possible that location may play a role in either part of the authentication process or authorization process, particularly if combined with context awareness. For instance a junior nurse may be allowed access to a part of a patient's record to validate the drug he or she is about to administer if they are recognized as being collocated with the patient but not otherwise, while a senior consultant physician may have full access to the record wherever they may be.

2.2.6 Hospital - Various emergency response systems Emergency response systems have various levels of clinical involvement, and often use a common infrastructure or even application as their routine counterparts. These are numerous and of a wide ranging nature, covering emergency clinical events such as a "Code Blue" patient resuscitation activity after a coronary event; emergency events with some clinical involvement; and non-clinical emergencies such as violent patients or lost or abducted patients, equipment theft, fire or hazardous material spills and releases.
Nortel Confidential 27 of 226 2.2.7 First responders -wide area secure mobility The first responders are often the first point of contact with critically-injured patients and require as much information about the situation as is possible but without overwhelming them with information, which is very easy to do in a high-pressure, high-stress first response situation. Furthermore they need to be able to communicate both what they are doing and the patient clinical situation back to the hospital so that the Emergency Room has some idea of what is coming in, particularly in the case of multiple patients, where the ER could be overloaded.

2.2.8 Clinics and physician's offices- SMB high performance solutions The Clinic or physician's office in a Medical Dental Building (MDB) is another location which both makes the first contact with a new patient and which also doubles up as a Point of Care, albeit usually in a less-stressed situation that the first response situation and with less complexity than the hospital. The clinic will both handle patients who only require treatment at that site and ones who will require further treatment in hospitals.
Hence both the first response and the ongoing PoC aspects of the Clinic/MDB
have a significant likelihood of being involved with a hospitalization, either as a precursor to or as a follow on from that hospitalization. Hence there is a need to integrate clinics and MDBs selectively into hospital information systems or at least allow the clinic's systems and those of the hospital to exchange information electronically. In cases where there is a 1:1 match between clinics and hospitals this is relatively straightforward but in MDBs where multiple clinicians have multiple different combinations of accreditations at multiple different hospitals the situation and solution becomes more complex.

2.2.9 Hospital groups and all other clinical information users - data centers with high quality BC/DR solutions Hospital sites are not stand-alone entities and are often associated with other hospitals in groups (either by ownership or by specialty), the other parts of the same hospital (e.g.
geographically remote departments) as well as supporting clinics, test labs, etc. Clinical data has to flow between these sites in a dependable secure manner and furthermore all clinical data needs to be backed up or archived so that it is retrievable should a disaster hit one of the sites, such that data at that site is lost.

2.2.10 Patient Involvement and Home Health- appropriate telehealth solutions As information and communication technologies advance and as the pressure grows within the healthcare system to keep patients out of critical care facilities for non-critical Nortel Confidential 28 of 226 care episodes (or for non intensive parts of critical care episodes) a requirement is emerging for home telehealth capabilities, either as a short term follow on/precursor to a hospital event or as a long-term alternative to hospitalization.

2.2.11 Mobile clinicians - wide area secure mobility solutions Almost all clinicians have highly mobile roles moving from patient to patient, role to role and location to location. Virtually never does a clinician spend the majority of every day in the same location or behind the same desk. That said, there are a wide range of required mobility levels. Experienced physicians may migrate from their Office of Practice in an MDB, to one or more hospitals, roam around the hospitals and even work from their home or their vehicle, especially in the first part of a patient emergency. A
homecare nurse primarily requires mobility in the wide area while a junior nurse in a hospital primarily requires mobility within one or two areas of that hospital.

This is not meant to be an exhaustive review of all of the areas of healthcare and the discerning and knowledgeable reader can readily add more areas not addressed here.
Over the last three to four years we have built up an understanding of what is needed in many of these specific areas and how to deliver it. The bibliography of previous documents provides a list of published material in this space. At the same time we have learned some of the fundamental limitations that exist in today's technologies and solutions, particularly around lack of advanced solutions and services functionality and have been researching some of these.

The first step is to treat the solution for Healthcare communications as a communications network and not as a bunch of separate sub-networks which don't necessarily inter-operate. This overall network (which may be a single network or a network of networks where the component networks are designed to properly inter-operate and provide a pre-defined overall capability and functionality) is shown in Figure 2-2 and comprises: -a) In-building solutions b) Wide area solutions c) Mobility solutions - in-building, out of building and both d) An overall networking excellence of the resultant solution, rendering the resultant network attributes compatible with the needs of mission-critical clinical services -leading to the concept of Clinical Grade Nortel Confidential 29 of 226 Clinicians need = In-building communications, especially in hospitals at the Point of Care and between/within the various supporting departments to PoC
= Wide area communications both fixed (e.g. to satellite clinics, other hospitals) and mobile (visiting clinicians, first response, specialist "on-call", home health workers, etc.) = Mobility solutions - to provide information connectivity in a suitable manner wherever they are = Overall Clinical Grade solution quality - so the clinicians can depend upon the availability of what they need and ease of use - so it doesn't obstruct their workflows Figure 2-2 Healthcare As A Communications Network The view shown in Figure 2-2 is driven by recognition that the communications and IT
infrastructure has to deliver what the clinicians actually need if those clinicians are to trust their patients, and their careers, to the newfangled technologies and capabilities. The clinicians need solutions which respect their mobility throughout the hospital and often beyond the hospital, especially for physicians, who may be moving between hospitals, outside locations, clinics and their offices, as well as throughout the hospital itself.
Besides mobility other factors, such as dependability, ease-of-use, strong security, etc. are also very significant and a poor rating on any one of these may result in a significant clinician end user resistance to the solution.

Within the hospital dependable communications to and from the clinicians at the Point of Care (with the patient) and Point of Decision (away from the patient) and to and from all of the supporting departments and databases are crucial if IT solutions are to become universally accepted at the Point of Care. In the context of this document Point of Care (PoC) is taken to mean both of these since, in reality, assessment, diagnosis, consultation and decisions take place both with and without the patient being physically present. Wide area communications, both in the guise of fixed (wired) and mobile (wireless) communications allow the clinician to stay in touch, to receive updates and provide remote care or remote care guidance - these involve networking between hospitals, clinics,, offices, clinicians' homes and vehicles, etc.

Nortel Confidential 30 of 226 2.3 Clinical Grade In order to achieve a satisfactory user experience the quality and design of the clinical communications solution has to be to a high standard, with the correct functionality, so that it can meet the demands of the clinical workflows once the workflows have evolved to maximally embrace this technology and the overall clinician population has fully embraced the resultant capabilities.

Nortel is proposing a Clinical Grade solution - based upon the concepts behind Carrier Grade solutions for the telcos and other carriers but in this case being based upon the requirements of mobile clinicians and mission-critical clinical services as opposed to the requirements of a large carrier network, which are necessarily rather different.

Clinical Grade networks have to deliver on 10 fundamental tenets, which are: -a) Availability b) Security c) Quality of Service (QoS) and guaranteed Service Level Agreements (SLA) d) Pervasive coverage of the facility and beyond e) Seamless mobility with session adaptation f) Transaction integrity g) Non-repudiation h) Provides an ability to evolve - "future-proof' i) Ease and consistency of human-system interactions j) Workflow supporting, workflow engaged and workflow enabling Some of these tenets have to be addressed in collaboration with the application providers since it will take collaboration between the infrastructure and the clinical application to provide the necessary functionality. Hence we will have to work with clinical application vendors in some cases. For more details on the background to Clinical Grade see Ref 7.
Furthermore, when ECAS is implemented as an aid or enabler to Clinical Grade solutions, it will have to itself meet Clinical Grade tenets. As an example not only does the 802.11 WLAN and cellular WAN coverage have to be adequate but so would the coverage of sensor and location services and hence the coverage of the basic solutions for these aspects (e.g. Ultra Wideband location technology) would have to meet Clinical Grade requirements.

Nortel Confidential 31 of 226 Solutions that don't meet Clinical Grade can (and are) still be deployed but are likely to result in some issues, either of technical performance, perhaps with security or authentication flaws or with inadequate coverage or availability or simply not enough throughput to do the job. These also risk triggering a backlash from the clinician community if the problems are severe. This backlash could raise the entry barriers for subsequent "fit for use" solutions by raising the skepticism levels further.

Achieving Clinical Grade solutions requires a detailed knowledge of how the solutions integrate into the workflows, what the traffic and activity levels are and what the end user preferences are, as well as meeting a set of fundamentals of good network and solution design.

Often it is the case that meeting one Clinical Grade tenet makes achieving another one more difficult. For instance the need for bulletproof security and authentication can lead to excessive system or application requests for the user to input passwords or other forms of identification corroboration, leading to a non-user-friendly solution which fails on "ease of use". Hence Clinical Grade solutions have to deliver simultaneously on performance, dependability, reliability, security, privacy as well as the ease of use needed by the end-user clinician community in a fully mobile solution.

Many techniques can be used to help make the design of such systems easier or to provide more advanced capabilities and a previous document (Ref 8) described how an Environmentally Aware Network (EAN) approach could assist. This document goes further in exploring how an Environment and Context Aware Solution (ECAS), which is really a superset of an EAN, can significantly impact Clinical Communications Solutions, delivering Clinical Grade functionality and achieving more advanced services capabilities which will integrate with existing workflow, enhance workflows or even enable advanced new workflows.

2.4 A Modern Pre-ECAS Hospital Information System Many hospitals are still stuck in a quagmire of paper processes and forms with the attendant risks, inefficiencies, staff distraction, lack of support tools, etc. The fortunate few hospitals have completed a transformation to a fully integrated digital Healthcare Clinical Information System (HCIS) throughout their facility, whilst the majority of hospitals are somewhere in between. These hospitals often have isolated islands of digital solutions in specific departments but no hospital-wide solution, or have a basic hospital-wide solution but do not yet have all departments effectively integrated into that solution.
The most-advanced hospitals will have solutions somewhat like the solution shown here.
Nortel Confidential 32 of 226 ---------------------------------Rad PACS S stem rchive/
index o o Mo PAC8 1 2 3 n ------ POC System-------------------------------------teorminal ~. ~ Ris Tertn Tertn Tertn Term "PoC yy.~c . ~ 1 2 3 n .................... Server" W-Attac ------------------------------- _ Wirele ss POC sub-system = 1~ . POC EtC. Etc. Gateway/
Access { Diet system 802.11 Scheduling '--------------------- wt_aN De aw F f Pharmac unchonat fi:]j e~ t HCIS eci tic -----------------------------------------------------------' Cardiology vS
stems Billing Gateway/
Laboratories Local Mod Mod Mod 1 2 n - Clinician ID, authentication - Clinician authenticated - Validating Clinician authentication primitives access - Validating Clinician/patient mapping - Terminal ID, type and - Authorized EHR, EPR, - Routing and fetching data to/from connectivity EMR data and test results various repositories based on - Patient ID according to clinician clinician requests - Requested information fields privileges, Patient ID - Order clinical validation - Input data and orders - Order validation - Limiting access to data e.g.
based on clinician-patient cross profile > Point of Care solution permits clinician to access information delivery, capture while with patient but can be cumbersome to use.
Figure 2-3 Hospital Information System - Wired & WLAN POC
Figure 2-3 provides a simplified representation of a modern hospital IT
solution, supporting clinician clinical communications at the Point of Care. The overall hospital infonnation system consists of: -a) The hospital clinical information system (HCIS) core, which links and supports the clinical databases of multiple departments and databases b) The departmental systems, many of which will have been acquired as stand-alone functions and which will have had to have been subsequently integrated together c) The local Electronic Health Record for patients in the hospital or who have been treated by the hospital - this may also be referred to as an Electronic Patient Record (EPR) d) Test laboratories with their different functions, modalities and outputs e) The Radiology Department with its suite of non-visible light modalities, Radiology Information System which may include a Picture Archiving and Communication System to move imaging data between modalities and diagnostic terminals and radiologists as well as archiving and accessing information stored in the Radiology Information database fJ Firewalled secure gateways out to other location for connectivity to centralized BC/DR, remote centralized EHR, etc.
g) A pervasive access capability throughout the hospital, both via wired terminals and via wireless to allow clinicians to access and input data, information and decisions. This has two parts - wired and wireless and is associated with secure Nortel Confidential 33 of 226 authenticated access to some form of a Point of Care server which will mediate between the multiple clinician requests for communication and the appropriate sending/receiving departments or databases.

Some of the required functions for appropriate secure access are shown in the text under the diagram of Figure 2-3.

The hospital model and assumed level of pre-existing clinical IT maturity as shown in Figure 2-3 will be the starting point for additional ECAS functionality roll-out as discussed later in this document. Both these roll-outs and the starting point will be characterized in far more detail at that point.

2.5 Clinical Scope To Be Addressed The earlier sub-sections of this section have painted on a very broad healthcare canvas and indeed there are opportunities to explore the application of ECAS in many areas and aspects of Healthcare. But we have to start somewhere and find the first small pond to boil before moving on to ocean-boiling. So we have to limit the breadth of our investigation, at least in the beginning.

The work in the rest of this document is comprehensive and detailed and digs deeply into several clinical and architectural solutions and application areas but it does so on a narrow front - addressing the needs of a medium sized hospital and even then focusing on the general clinical areas of that hospital, but for now excluding Radiology and Operating Rooms (OR).

The process to be followed will be to understand the basic attributes of ECAS-based solutions, to understand a representative suite of pertinent clinical applications to understand how and where ECAS can help, the nature of that assistance and the resultant change in the workflows, to evolve hypothetical use-cases or scenarios around the ECAS-enhanced workflows and use this to calibrate the parameters required for a successful ECAS solution.

We will then apply this learning to a hypothetical hospital, based upon a real-life hospital plus the necessary clinical models we either have to assume or have data points for. This will allow us a first insight into the nature of an ECAS-enabled hospital infrastructure.
We still have to do the economic modeling and the roll out scenario analyses so these are not contained here and remain a target for priority work in 2007.

Nortel Confidential 34 of 226 3 What ECAS Capabilities Can Do One of the ways communications networks are evolving is for them to become more intelligent due to the application of processing within the network, to the point where intelligent decisions can be made based on the context of the network circumstances or situation. At the same time technologies are emerging, often driven by homeland security pressures, to allow the monitoring, tracking and measuring of the physical world in new ways that allow an intelligent network, including an intelligent communications network, to be aware of the physical world and to interact with it. These two capabilities, when applied in a structured way to a communications network, provide the basis of an Environment and Context Aware Solution (ECAS). A preliminary overview of the ECAS
concept was issued earlier this year -see Ref 9.

The Environment and Context Aware Solution approach can provide adaptive, smart communications, based upon an awareness of the physical world, including personnel and equipment location, identity, proximities, physical environments and deduced situations. This is combined with an ability to access permissions and authoriza.tion/
authentication profiles for actual or prospective users (human or machine) as well as other databases including policy databases which define how the system should respond under various situations to achieve the organization's required results, regarding the subject communication area. Communications based on ECAS can also take into account the status or condition of the communication network itself.

From this set of inputs - environment, informational databases and policy, resource and infrastructure databases as well as network databases - the Environment and Context Aware Solution can make intelligent assessments of the situation, as well as the resultant required adaptation of its communication, ranging from modifying the form of communication right up to initiating communication or other actions or altenlatively preventing communication or other actions from occurring.

An ECAS network, solution or capability can be overlaid in stages on top of an existing infrastructure, albeit with some adaptation of that infrastructure. This can be implemented all at once for a massive change in capabilities or can be carried out in stages, for instance making the necessary connections within the core databases to allow the addition of a context server and hence context processing, prior to overlaying a staged roll-out of an environmentally aware capability, perhaps by initially adding location software to the WLAN, then adding a sensor capability, then upgrading the location solution to a precision location solution to allow real-time equipment-personnel and personnel-personnel associations, to add various stages and levels of ECAS functionality as required. It is important to remember that this modularity is innate to ECAS
since otherwise this document might paint a picture of a monolithic solution which is not the reality here.

Nortel Confidential 35 of 226 3.1 Building blocks of ECAS

The key components of an Environment and Context Aware Solution are a superimposed Environmentally Aware System and a Context Aware or Context Responsive System, both of which contain multiple functional subsystems.

The basic and generic structure for an ECAS system is shown in Figure 3-1 and the following sections will explore the various aspects of this structure.

ECAS works with the context of authenticated users to provide for their needs, and adapt to non-nominal context or environmental situations Figure 3-1 Basic Structure Of An Environment/Context Aware Solution 3.1.1 Environmentally Aware System Environmentally Aware Systems use information acquired through environmental monitoring such as location detection, sensor arrays or grids using sensors sensitive to specific factors such as heat, light, pressure, presence of toxic materials or gases, radiation, etc. or more complex sensors for heart rate, blood pressures, etc.
to determine the situation in the physical world and from this to provide outputs that can be used to modify responses or activities. A clinical example would be "The `Code Blue' emergency is in room 392 - where is the nearest physician and crash cart?"

The key components of an Environmentally Aware Solution (EAS) are: -Nortel Confidential 36 of 226 - Sensors, transponders (e.g. RF-ID tags and others) and other data-gathering capabilities to interface with various environments - A communications network to/from the sensors/transponders and to/from machines and people within the scope of the EAS

- A coordination and processing function, associated with a set of policies, which generates useful information and decisions from the input data from the sensors and which can be output for the purpose of adapting the behaviour of the network and delivering sensor-based information and decisions to client applications 3.1.2 Context - Responsive Solutions A Context Aware (or to be more precise, a Context Responsive) system modifies network responses / activities based upon on situation-contextual information derived for one or more sets of input data points or planes, such as the known parameters of the users, groups, environment, transaction content, source or destination, security, privacy, current assessed "global" or local situation or any other similar set of attributes. A
clinical example would be "The emergency `Code Blue' team requires a set of skills -establish contact to on-duty clinicians with those skills and identify which crash carts are functional and available".

The key components of a Context Responsive Solution (CRS) are: -- Positive identification of end user people and machines & their status, requirements, authentication profiles and an ability to collect or derive other context information - A communications network to/from the content servers and policy servers to provide the raw data and policy frameworks for context decisions and to/from machines and people within the scope of the CRS

- A coordination and processing function, associated with a set of policies, which makes the context decisions and adapts the behaviour of the network - Methods for applying policy both into the relevant context decision processes and into the voice, data communications flowing between users, who/which can be people or machines 3.1.3 Context - Responsive & Environment Aware Solutions Context Responsive and Environmentally Aware Solutions are usually referred to by the less accurate but simpler name of Environment and Context Aware Solutions (ECAS).
They modify their network responses or activities based upon on combining contextual Nortel Confidential 37 of 226 decision-making and environmental inputs. It uses these (e.g. known parameters of users, groups or known situations plus using data recovered from environmental monitoring) to determine a course of action leading to modification of responses or activities.

A clinical example would be "A `Code Blue' has been called in room 392 -Determine the matching key set of required skills, which clinicians have those skills and where the nearest available (non-busy) on-duty clinicians are with those skills to the "Code Blue"
site - those are the Clinicians contacted first - and also determine the location of the nearest available functional crash cart (one in good repair, clean and with charged batteries, not currently in use on another patient) and identify a nearby and available orderly and send him to go get it."

3.2 ECAS Attributes There are a wide range of factors to consider for the ECAS concept. Some of the more significant ones follow.

3.2.1 The need for smart communications Smart communications may achieve a number of benefits. These include: -- Matching the communication format to the needs and abilities of the user situation - for instance a clinician who is a senior physician dealing with an emergency clinical situation may have different communications requirements than a junior nurse doing routine patient checks.

- Matching the communication structure to the capabilities of the end user device -for instance a clinician using a large screen tablet Personal Computer (PC) may receive data in a graphical or image form while another clinician using a small screen PDA would receive the same data in a different form, perhaps several pages of text or tables.

- Assessing the overall situation and modifying communications content appropriately - for instance a physician accessing a PoC system while with a particular patient (= in proximity to that patient) may be guided preferentially to the records for that patient instead of having to find them. Assessing the authentication status and terminal/personnel association status and modifying re-authentication requirements appropriately - for instance if a clinician is authenticated to his or her tablet PC and the tablet PC is tracked as traveling through the hospital with the clinician then it remains an authenticated device but should the clinician and the tablet PC become non-proximate for a period of time then a policy is applied that eventually leads to suspending or terminating authentication. Should the tablet PC start traveling a significant distance from the clinician then its authentication becomes suspended or terminated immediately.

Nortel Confidential 38 of 226 - Identifying appropriate physical world parameters, deriving the situation and either initiating or modifying communications as a result - as an example when a tablet PC or other piece of equipment is detected as traveling out of its approved zone, based on organization policies then appropriate action can be taken. As an example a tablet PC, normally proximate to a specific clinician may be detected traveling through the hospital without a continuously proximate clinician - in that circumstance the application of policy may determine that the device is likely being stolen, since all employees can be tracked and no-one is being tracked with this device, and appropriate security or theft prevention protocols can be activated.

It is anticipated that the resultant impact of smart communications, especially environmentally aware smart communications, will be substantially more effective, more capable, more-fit-to-purpose (appropriate), easier-to-use and anticipatory communications, all of which will find ready acceptance amongst the user community.
This is due to these attributes making their workflows and hence their professional lives, more convenient, more productive and more comfortable, both through major and strategic changes (ECAS-enabled workflows) and a host of minor changes such as simpler authentication, more appropriate and more secure communications and protection should they inadvertently leave their laptop or tablet PC lying around.

3.2.2 Environmental Awareness Environmental awareness may be as simple as an ability to approximately determine a basic environmental parameter such as a location or a temperature or may be a sophisticated, precise ability to calibrate and relate the situations in or across multiple environments or factors such as location/proximity, temperature, pressure, radiation levels and types, the presence of various hazards (smoke, toxic gases or chemicals, harmful radiation, bio-toxins, etc.). No matter the level of sophistication this environmental awareness requires three things, being the actual environmental sensors or detectors, a method of back-hauling the data from these to a central point or points and a method of processing the data to derive useful information.

Typically this may take the form of various sensor and location networks using wired or wireless backhaul. Wired backhaul is more dependable and can be more secure but is expensive to install and is often geographically limiting unless the sensor density is low.
Wireless backhaul is more convenient and can be cheaper but raises issues of the quality and dependability of the RF channel as well as the powering of the sensor node, since powering it over the (now non-existent) wired infrastructure is not an option.

The sensors may be passive or active devices. For instance an Ultra wideband transmitting tag and a set of location triangulation receivers make up a location sensing function by use of active technology, while a simple thermocouple can make a passive temperature difference sensor (although in this case this would have to be combined with an active digitization and transmission function to backhaul the thermocouple output Nortel Confidential 39 of 226 voltage values). A simple door closure contact switch is another example of a passive device.

The collected sensor data has to be processed to extract useful information.
For instance a single UWB receiver output cannot provide the location of a transmitting tag, other than it is somewhere within range of the UWB receiver. However combining the measurements from 3 or 4 or even more location receivers allows the determination of the location of the tag in 2-D or 3-D space to extreme precision -theoretically +/- 3" or 7.5 cm in each axis, although current commercially available systems usually exhibit an error range of about 4- 8 times this - but this is still very precise.

Often the extracted information from one sensor type has to be compared with the extracted data from other sensor types in order to make a situational determination. This is crossing over into the Context or situation assessment process.

3.2.3 Factors determining context Context or situational awareness can be determined by combining information from many sources. These include the activity and activity history on the communication network, the environmental situation of the network users, the nature of the intended or actual use of the network by the users, centrally stored information about the users, be they people or machines, such as their authentication status, authorization and permissions profiles as well as the policies of the organization or facility which can be used to assess when a situation requires a response and the appropriate nature for that response 3.2.4 Context decisions Context or situational decisions are made by a Context Server or processor by bringing together and processing the information derived from the data from physical senses, as measured by the various environmental sensors or non-physical, derived from a system database, such as authorizations and permissions for specific users under specific circumstances. This information is processed to determine the situation, which policies are relevant to the situation (by comparing the situation parameters against policy activation parameters) and the policy directions or required actions. From this the Context Server deduces an appropriate set of actions and initiates these either directly or by sending instructions or requests to the appropriate destinations for action to be taken.
For instance, in further reference to the example cited in Section 3.2.1, whereby Tablet PC migration is detected, the Context Server may determine that Dr. Smith was in the middle of a patient PoC session when his tablet PC started moving through the building rapidly without being in the presence of a member of staff so will immediately de-authenticate the machine and cause it to forget its clinical data. As the tablet progresses through the building it becomes clear to the Context Server that the tablet may exit the Nortel Confidential 40 of 226 building so it causes appropriate surveillance cameras to be directed on the location of the tablet POC and notifies the Security resources of the potential theft in progress, flashing them a picture or video stream of the culprit. In the event the culprit reaches a door he finds that it will not open and an alarm sounds, triggered by the Context server.
Alternatively if Dr. Smith finishes his PoC session and then he walks quickly towards the exit with the tablet PC the Context Server notes that the authorized user plus the Tablet PC are traveling in concert and may cause the machine to require the entry of a password or biometric known to Dr Smith if the unit is taken out of the building (so that it cannot inadvertently be left "open" in a public place since the location system ends at the hospital door. The act of Dr. Smith taking the unit out of the building results in the Context Server detecting this and notifying the Tablet PC inventory control Server (if there is one) that Tablet PC serial number XYZ is now in the exterior possession of Dr.
Smith. It does not trigger a security (theft) event.

In yet another example Dr. Smith may be in the middle of a PoC encounter when his Tablet PC starts moving rapidly through the building, this time traveling with an employee who is a member of the IT department. At the same time Dr. Smith may initiate a log on to another machine or another Tablet PC may be detected to be unauthenticated but to be in the presence of Dr. Smith. In this case the Context Server may deduce that the original Tablet PC is now in the hands of a maintenance technician and will track it to ensure it reaches the IT deparhnent and will transfer Dr Smith's session from the original machine to the replacement Tablet PC proximate to Dr Smith and simply trigger the replacement Tablet PC to request Dr Smith to enter his biometric ID to confirm he wants to continue the session on the new Tablet PC.

All three scenarios result from an authenticated Tablet PC in the hands of Dr.
Smith suddenly heading rapidly through the building but the situations are very different and the Context Server discrimination of these different situations allows for very different and appropriate actions to be taken each time.

3.2.5 Bringing environment and context together Context can be derived simply from within the communications system activity itself (network context), either using simple traffic loads and availability of resources or on more detailed information such as which users are accessing which classes of information or which users are accessing which servers or even which groups of users are, from a network attachment perspective, in the same general vicinity and what their combined skills would imply might be the situation. This can be combined with the knowledge of permissions and profiles and the application of policy, and without environment sensing data input, but the scope of these context decisions is limited by being blind to the real world (user context).

Adding environmental awareness adds additional scope for better, more comprehensive and more valid /relevant context decisions to be made. This ability increases in Nortel Confidential 41 of 226 proportion to the brilliance and scope of the environmental visibility granted to the Context process. Hence there is an emphasis on the precision and accuracy of environmental characterization data as well as the comprehensiveness of environmental sight. For instance an environmental visibility of only location information is not as useful as having visibility of location, heat profile, toxic gas and smoke distribution and visible or infra-red radiation in a situation where a fire has occurred and the system is responding to that emergency situation.

There is also a need for appropriate levels of precision and accuracy for each situation.
Precision and accuracy are not the same thing. For instance to associate a Tablet PC with a clinician may mean detecting that the Tablet PC is within the personal zone of the physician - which extends for 2-3 ft (60-100 cm) around him/her, primarily being in front of the clinician. A location system with a precision of +/- 5 feet/ 160 cm cannot do this because it is too imprecise, whereas one with a precision of +/- 6"/15 cm can.
Since the Tablet PC may be used for sensitive data the system has to accurately associate the Clinician to the Tablet PC which means that, if the location system is to be the main determinant of this, it must have a very high accuracy, perhaps 99.99%, since even this would result in a mis-authentication for 1 in 10,000 activations, which may lead to a potential exposure of medical information once every few days in a medium sized hospital. For this reason a location or other environmentally derived authentication is likely to be part of an authentication process rather than the whole process.
Nevertheless it can radically simplify the rest of the process, thereby reducing user fatigue, and can provide safeguards against the rest of the process making errors. For instance if Dr. Smith is on the 3rd floor and suddenly his ID is being used to access the system from the 15th floor it is likely that an illegal or illicit activity is under way based upon a stolen, duplicated or misappropriated ID and appropriate safeguards can be taken.

3.2.6 ECAS and Clinical Grade Clinical Grade solutions have to meet a very stringent set of tenets, some of which produce contradictory pressures on the implementation of the Clinical grade solution.
This leads to significant difficulty in the solution design and to some trade offs being made - for instance highly secure systems can be noticeably burdensome in terms of continuous authentication and frequent shut-outs/denials of access, yet the ease-of-use requirements need the opposite - simple, non-burdensome access and authentication and very few illegitimate denials of access - which often leads to an insecure system.
Similarly, as clinicians move between locations, roles and patients they need their communications to remain dependable and relevant, matching their needs, for instance providing information that is relevant and in a form which matches their needs and the capabilities of the terminals (hand-held or static) they are currently associated with as well as the networks they are connected to. All of these can be assisted by the capabilities endowed by ECAS functionality.

Nortel Confidential 42 of 226 Some of the areas of a Clinical Grade implementation that can be impacted by an ECAS
approach include availability, security, quality of service, pervasive coverage, seamless mobility with session adaptation, transaction integrity, non-repudiation, ability to evolve, ease of human-system interactions, especially around ease and consistency of use, and engagement into the workflow. The values of these, and some of the areas where ECAS
can have an impact, are identified below.

3.2.6.1 Availability Availability is critical for IT solutions integrated into clinical processes, because when the IT solution is not available then either the clinical workflow is non-viable or is impaired or a back-up manual process has to be deployed. But equipment does fail -that's a fact of life - it is just a matter of how often, to what extent and how the solution is designed to mitigate the impacts of equipment level failure and to keep the services functioning. In the event of equipment failure ECAS-based location and identity of users, possibly combined with their current situation, role or activity can be used to adapt or optimize the protection/restoration response to ensure adequate coverage for critical users.
This would result in increased service availability during times of partial system failure and would minimize the impacts on those users who most need the system capability at the time of the partial failure. Furthermore exposure of equipment to out-of-spec environments, conditions or which require maintenance activity can be detected and alarmed by the environment-aware aspects of ECAS. This allows the correction of some of the root causes for a failure before it happens, which should result in overall better service availability.

3.2.6.2 Security In a Clinical Grade solution security of the network and privacy of clinical data is extremely important. Security includes protecting the network against unauthorized access to the network, and matching authorized and authenticated (Dr. Smith really IS Dr.
Smith) access to information to permissions as to who can access what. The Clinical Grade network also needs to be protected against attacks, which will allow the network functionality to be compromised or which may allow an unauthorized person access to medical information. This is driven both by a privacy concern and by a need to ensure that medical records cannot be tampered with, which would destroy the integrity of the clinical databases.

In addition, since much of the end user terminal base will consist of small, portable, often pocket-able devices, security against physical theft of these devices and the information they may contain is also vital. Since hospitals are open public places the opportunities for theft of small portable pocket-able devices is high and a viable solution has to safeguard against excessive loss of hand-held equipment. Yet another form of security is the physical security of the patient, with young patients being secure from abduction and Nortel Confidential 43 of 226 with older patients not being able to become "lost". While this aspect is not a Clinical Grade aspect since it covers physical security and not security of the Clinical Information System the Clinical Grade Network may be able to play a role in maintaining a level of physical security of patients through the use of ECAS.

ECAS allows location based identification and tracking of people, objects, location and sensor (biometric) assisted log on and authentication, authentication duration based on clinician-terminal proximity and location, detection of suspicious movement of unattended terminal, cyber- "corralling" of equipment. ECAS can therefore become part of an overall comprehensive security and privacy solution for a Clinical Grade network.
The net result would be to reduce or prevent theft and to prevent losing elderly or very young patients, improved clinician identification, authentication, and improved information security. Access privileges into network can be dependent upon location-based analysis (e.g. of terminals, users, equipment or combinations thereof) and/or other situational analysis by the context server.

3.2.6.3 Quality of Service (QoS) & guaranteed Service Level Agreements (SLA) One of the big uncertainties in a true Clinical Grade network is how much capacity to provide and how to implement a capacity resource allocation scheme to achieve a satisfactory of better Quality of Service for all users. This is because we anticipate that the deployment of Clinical Grade networks will radically reform clinical practices with clinicians moving from practices which generally assume the non-availability of comprehensive information services to clinical practices that assume the availability of advanced clinical IT support services, which will trigger a radical change in the way clinicians use the network.

Unfortunately no models currently exist for the impact of this change on the actual network traffic and the resultant requirements on the network. This risk can be ameliorated by over-dimensioning the network but this will add extra cost. In addition and especially if we cannot rely entirely on over-capacity to solve the QoS
issue then various forms of QoS management beyond those available in the best effort IP
world may be required. These can be made significantly more sophisticated if the QoS
management system has visibility of the specific user needs and location at any point of time.

Some of this information can be contained in a user profile, often by class of user (Physician, Nurse and within this, Junior, Experienced, Senior, Specialist type A, type B, type C, etc.). But these only respond to the user ID and class. It also needs to be recognized that the QoS needs may be a function of workflow status, location, association with specific patients or with specific equipment, the nature and capabilities of the hand-held terminal, etc. ECAS can identify clinician terminal needs, capabilities, connectivity, workflow situation, user credentials which can then be used as inputs into any QoS partitioning or resource allocation scheme (workflow-optimized QoS
modification) that is required.

Nortel Confidential 44 of 226 This may lead to the QoS characteristics being modified according to users credentials, terminal capabilities and workflow situation, leading to a better apportionment of communications resources which in turn will permit a better tolerance of uncertain growth in traffic load as the clinical processes evolve and clinician uptake rises as well as better emergency response, and better user satisfaction in routine operation.
3.2.6.4 Pervasive Coverage of the Facility and beyond The deployment of clinically enabling IT into clinical processes requires that that clinically enabling IT be dependably available to clinicians whenever and wherever they need it. In the context of hospitals and Point of Care communications this requires a pervasive coverage of the hospital with wireless LAN since this is likely to remain the technology of choice to communicate to busy mobile clinicians in the hospital for many years to come. This will require a ubiquitous coverage of the hospital floors with a high throughput-capable signal, since a Point of Care episode can occur almost anywhere in the hospital, not just at the patient bedside. Current wireless LAN solutions, especially those deploying 802.1 lb or 802.1 lg, have serious difficulty meeting this requirement since, with only three orthogonal channels available, deployments dense enough to overcome the radio-shadowing effects of building structures are also dense enough to create their own common channel interference and as a result a high number of "dead spots" where signal strength may be high but the available throughput is essentially zero, due to Common Channel Interference (CCI).

Hence it is anticipated that Clinical Grade solutions may primarily be deployed in future based on 802.11a (with 12-13 channels) or hybrid 802.11a/g solutions (with 15-channels). However, even with this approach situations may arise whereby a traffic hotspot (e.g. clinical activity around a medical emergency situation) may locally overload the WLAN network, and in addition service must be maintained in the event of an AP
failure or the AP being disabled by an external event. ECAS can identify clinicians, their location, their terminal type and location as well as their workflow situation and provide information to an adaptive-coverage physical layer - e.g. steer-able/shapeable antennas, the forced redistribution of traffic to further APs for load-balancing adaptive power control solutions or to select alternative delivery methods. Given the variability of WLAN coverage, this will create the same effect as better WLAN coverage and throughput creating better service delivery, and more acceptable system performance for the end user.

3.2.6.5 Seamless mobility with session adaptation Clinicians have to be mobile. For hospital nurses this usually means mobility within the hospital or primarily in the hospital and therefore mobility within a Wireless LAN
network. Home care nurses need mobility which encompasses home visits, inter-building (Wide Area Network) mobility and mobility for a part of their time within the base Nortel Confidential 45 of 226 hospital or clinic. Physicians often require mobility within the hospital, the outside environment (Wide Area Network) as well as in their point of practice, usually in a Medical Office or Medical Building/Clinic and at home. This mobility often has to be seamless in that the clinician has to be able to roam between nodes on the same network or between nodes on different networks and still maintain a continuity of service. For instance a physician talking on a WLAN-connected phone who continues to talk on that phone should not experience a dropped call when he or she exits the building and passes out of range of the WLAN. Instead he or she should be transferred smoothly and seamlessly to the external cellular network.

Furthermore any session in progress should be adapted so that it can be delivered by the disparate capabilities of the various candidate networks. For instance WLAN
has a much higher bandwidth/data rate delivery capability than does a cellular WAN
network. Hence the applications and session in progress may have to be adapted to meet the constraints of the new delivery path. This may mean slower screen loads or lower resolutions, or alternative less bandwidth-intensive methods of delivering the service, such as basic text instead of rich graphics, slow-build images instead of fast high resolution images or video, etc. Many of these changes may be visible to the user but must be delivered in a way that the user can get to understand, even anticipate the changes, perhaps by providing a warning of an impending change.

For instance a message or indicator visible to the clinician could be delivered. This would allow the clinician the opportunity to change his or her trajectory and avoid the session transfer or hand-off, either until the end of the session or until the session reached a appropriate point. For instance a clinician involved in a session which involves reviewing a video clip may be viewing that clip as he or she approaches the hospital exit. A flag from the system would allow the clinician to delay exiting the building until the video clip had finished since such a clip would not be supportable on the external WAN
network. Once the clip is over the clinician can continue the session and exit the building, perhaps receiving lower resolution more plainly presented text data instead of the rich high density text/graphics received inside.

Of course some services, notably those that can fit within the cellular network bandwidth such as Voice, can operate truly seamlessly without service reformatting as long as the basic connectivity can be maintained across the transfer. The identification of the changing clinician proximity to a mobility event horizon, resultant expected time of arrival at a hand-off point and the session adaptation required to meet the needs of the networks and of the clinician can all be derived by the location, context and situation analysis capabilities of ECAS.

Identification of location, user/user profile and context of the needs of the clinician allows a better mobility solution which in turn allows the communication system to better shape communications to clinician needs, and to provide the best available delivery solution. It is noted that for this vision to become reality the "black hole"
problem of users losing visibility of one network before the new network can acquire and connect Nortel Confidential 46 of 226 them, as well as other problems, must be overcome. This can be addressed in several ways and has been the subject of a companion program.

3.2.6.6 Transaction integrity In a Clinical Grade solution it is important that critical transactions not only always complete but are validated and logged as completing. While in Carrier Grade solutions some data can sometimes be silently lost (for instance some voice samples during a protection-switch event) it is not satisfactory to silently loose any data in a Clinical Grade solution, since any data packet may contain critical information - e.g. a drug prescription order from a clinician to the pharmacy. Such transactions cannot be silently lost and both their origination as a timed event from a specific user and their receipt at the destination (in this case the pharmacy) must be logged - this is for event tracing in the event of a malpractice claim later and to meet certain legal requirements. Integrity checks based upon location as well as the source ID allow the further confirmation of key aspects such as "Dr. Smith was with the patient at the time of order" or "Dr. Smith has used the system ten times in the last 10 minutes from the 3`d floor and still is located there - the transaction ordered in his name from the parking lot needs investigation".

3.2.6.7 Non-repudiation The capabilities of ECAS can be used to establish the movement of clinicians and patients through the hospital and note associations at the time of transactions. Hence it will be possible to confirm, if the appropriate records are kept, which clinician did what -for instance if Nurse Jones administered a drug at 5:30 pm and Nurse Smith administered the same drug at 6:00 pm causing a drug overdose, this could be determined both from the closed-loop pharmaceuticals administration records (which shouldn't have allowed this event to occur) and from the location transaction log. Hence an ability to track and log vectors of clinicians, patients, establish and log temporal-spatial proximity occurrences, especially around the time of controversial events (e.g.
detecting the root cause of a medical error) may be very useful not only to find the causal person but also to exonerate those who were not. Hence ECAS will allow easier creation of event histories, backtracking to establish chain-of-events.

This also can be useful in other circumstances. For instance, in Toronto, during the SARS
crisis a capability such as this, overlaid on to a temporal map of when the victims developed the disease, may provide useful data to allow earlier determination of the method of propagation -in this example via clinicians. (This was an observation from a significantly placed clinical resource involved with SARS within the Toronto health community so isn't as far fetched as it sounds) Nortel Confidential 47 of 226 3.2.6.8 Provides ability to evolve -"future-prooP' If the vision of advanced clinical communications systems revolutionizing the practice of healthcare, specifically making it more efficient, more effective, safer and enabling new clinical workflows is realized, then not only does the practice of medicine change but so does the way clinicians use the communications systems and information systems, how and when they use them and to what degree. We do not know enough about this to project the impacts on the communication systems and IT systems themselves from the modified workflows and from the increased expectations of clinical users.

Literature searches have turned up no interdisciplinary studies of the nature of the impact of IT on clinical processes, which then in return characterize the impact the revised processes have on the demands upon the IT network, yet if the vision of IT
radically changing clinical practices is realized there surely will be an impact on the IT network.
We are in fact working to sponsor academic research in a number of areas that may give us an insight. However we do know that, if we are successful, the amount of use will increase radically and probably rapidly, and that there will be an expectation of an ability for the systems "to keep up" with the evolution of clinical practices, and the increased expectations for services and capabilities, some of which will be radically different to the capabilities of today's networks.

In this context ECAS will enable a new location, environment and context-based or situation-based services infrastructure; will allow the widespread use of handheld devices, by mapping communications content to match to the context of terminal capabilities, connectivity, user profile and situation; as well as providing theft protection for portable devices and monitoring of terminal condition and even medical equipment location and condition. This should result in a better user experience with the use of hand-held devices.
Less hand-held losses encourages adoption, which in turn encourages more capable, intuitive and "mission-optimized" future services as well as providing increased flexibility to adapt to new services and functionality requirements as the clinical workflow evolves.

Since the future requirements on Clinical Solutions will be uncertain and will continue to evolve as clinicians find new ways to exploit the solutions, the solutions themselves must be modular, adaptable and capable of being phased into the solution in stages so as to achieve an economically sensible roll-out out. This is true of any solution, and will be true of both ECAS solutions and the ECAS components of those solutions.

3.2.6.9 Human-system interactions - ease and consistency Communications and information systems can be cumbersome, awkward to use and daunting to non-technology-literate people. Clinicians are expert in their fields but not necessarily in computers, communication or IT so solutions must be easy to use and dependable in behaviour if they are to find widespread acceptance. Furthermore Nortel Confidential 48 of 226 clinicians are an aging workforce, with a significant and influential population past 40 years of age, where there is an increased resistance to new approaches. So again the benefits of clinical IT within the clinical processes themselves must become obvious and not compromised by solutions that have a long learning curve or which distract the clinicians in the middle of clinically intensive activities.

Unfortunately user-friendliness, dependability and ease of use may clash with other Clinical Grade requirements such as security (and the need for continuous authentication state monitoring), and mobility, where the clinician will require connectivity and services to be maintained wherever they are practicing medicine - for a hospital nurse that means throughout the hospital but for a senior consultant physician that means throughout multiple hospitals, his or her practice/office site, home, and while he or she is out-and-about in the city, country or even across the globe. Achieving the correct blend of ease-of-use, performance, dependability and security is a challenge and we will need multiple tools to achieve a best-in-class result.

It is believed that ECAS can contribute to this result in a significant number of ways. For instance using location, proximity, clinician profiles, patient association profiles and access privileges to better tailor the data the clinician is presented with are expected to simplify authentication processes and reduce their frequency of occurrence while remaining highly secure. Another example would see clinician services and connectivity tailored to their work situation and where they are - e.g. the surgeon entering the scrub room to prepare for surgery would automatically have his or her calls diverted, but that same surgeon in the same scrub room, having completed the surgery, would now receive his or her calls. The intended result is to achieve easier, more convenient clinician interaction with information technology, delivery in form appropriate to clinician-network link, clinician situation.

3.2.6.10 Workflow Integration The real value of Clinical IT and Communications will arise as it integrates into clinical workflows, allowing new checks and balances, much more ready access to previous histories, treatments of the patient as well as to information data-bases, consultation resources, workflow and decision support tools and decision and entry tools.
This will transform clinical practices and workflow from isolated experts making their best decisions or delivering their best care in relative isolation to an ability to collaborate and cooperate to achieve the best possible outcome or to validate treatment options or steps.
Understanding clinician associations, situation, location, proximities, etc.
allows communication form and content to be adapted more appropriately. Hence ECAS
should allow easier, more convenient clinician interaction with information technology, better formed, and prioritized information delivery, in form appropriate to clinician-network link, clinician situation.

Nortel Confidential 49 of 226 4 Generic Clinical Infrastructure Solutions for ECAS
This section examines some of the fundamental alternatives for providing solutions to deliver the kind of capabilities being described in the previous sections. It is a preliminary view, in that while the current hospital IT infrastructures are known, they are rapidly evolving and incorporating components of ECAS on a needs and budget-driven basis; thus alternatives are envisioned and require ongoing rationalization.

4.1 Application-specific versus generic infrastructure Tailored solutions can be designed for each application area. For instance a set of RFID
readers on doorways at department entrances and at the main doors of the facility combined with RFID tags could be used to alert for equipment theft and for equipment exiting the department. However such a basic system would not be able to discriminate between a theft and a harried clinician "borrowing" an item in an emergency from the next department. Neither could the RFID solution support locating equipment inside a department, let alone the association of that equipment with a clinician and/or patient during a point-of-care encounter.

Individual solutions will each have their own unique characteristics and will require specific clinician training to use as well as specific support from the IT
department.
When multiple such systems are deployed the training and interworking issues can become too onerous for clinicians to accept. From this perspective a generic architecture that can be used by multiple applications, but with at least family-similarity of operational interfaces and characteristics is to be preferred.

Individual application-specific systems are being deployed on an ad hoc basis.
As the ECAS edge devices, sensors, RFID tags, and location systems become increasingly networked and their physical and information interfaces more standardized, the system will evolve towards a generic infrastructure. This evolution will also be driven by the need and recognition that the generic infrastructure enables far more applications.

4.2 ECAS as a Generic Infrastructure To progress towards a generic infrastructure, the ECAS project has sought to identify reusable processing, data structures, and policy frameworks. To capture this concept, `ECAS templates' have been defined. These Templates are highly cohesive aggregations of knowledge and algorithms that interact with various ECAS subsystems and components and which may assemble data from a range of sources outside the ECAS
system, e.g., from External Expert Systems (e.g. contained in the HIS, HCIS or from a centralized EHR/EMR/EPR) and External Infrastructure Services. These Templates make this information available to applications and other Templates through common agreed interfaces. In practice, Templates generally have analogs in today's communications offers; the ECAS system expands upon these functions to perform a wider set of related functions. For example, the Geospatial template described later in Nortel Confidential 51 of 226 this document expands on what we today know as "Location" services. Figure 4-1 shows the ECAS solution using templates. This solution view was originally developed for a disaster scenario use case and has been adapted to healthcare to test its generality.
Figure 4-1 ECAS solution for healthcare, using templates.

The figure shows a workflow manager containing the reusable templates and the associated subsystems. The workflow system design and policy is entered by the decision maker and information expert, to drive the clinician and machine workflows.
Templates include:

1. Geospatial 2. Communication 3. Personal Profile 4. Resource Status 5. Emergency Services 6. Sensors 7. Custom templates 8. Interfaces to other systems To understand the kind of information and processing in an ECAS template, consider the geospatial template, taken from Ref 10:

Nortel Confidential 52 of 226 The Geospatial Template's basis in today's communications systems is "location"
services. Through interaction with external information sources and other templates (e.g. the Sensor Template), this template can gather additional context information and perform a richer set of services, in general fusing multiple data sources into a coherent picture to:
= Help in management: answering questions such as "where is everything?";
"where has it been?"; "where is it going?"; and to resolve geospatial relationships.
= Offer, in future, enhanced visualization mechanisms.
= Integrate analytic environments for geospatial and location information and services GeoSpatial +WorkFlowMap +WorkerLocation +SensorLocationMap +NetworkElerrentMap SiteMap +Cak:ulate DirectionQ
+CakulateSpeedO ZZ:
+CalculateProxinityQ BuildingMap +CalculateOnTrack() +Ca Icu lateShortestPath() + M a p Pa t hO bst ruct io n s() +CalculateMaxPossibleSpeedO Un ive rsa lLocation Se rv er +CalculateETAQ

Figure 4-2 Geospatial ECAS template.

The Geospatial Template shown in Figure 4-2 is expected to be widely used because it is applicable to many scenarios. This template presents on a task/workflow dependent scale.
It has a high level identity function (e.g. naming) in order to determine what object is where and relationships with others. It may infer position, direction, and speeds as well as predict certain future problems such as two vehicles being in the same space at the same time. It may also calculate near optimal paths, estimated time of arrival, and understand specific dependencies such as needing three objects to arrive to the same location within 30 seconds to enable emergency services personnel to adequately conduct operations. In a medical "Code Blue" scenario, both clinicians and equipment must reach the patient within a minute or two to try to prevent death from occurring.

A mature Geospatial template will provide a fully-integrated analytic environment for geospatial and location information and services. Expert systems such as a Universal Location Server may be used which would simplify and enhance the Geospatial template.
Any other template requiring geospatial information is directed to this template with well known interfaces.

Nortel Confidential 53 of 226 These templates can be implemented in the form of a SOA architecture, recognizing that any chosen implementation would need to accommodate the timing and performance requirements of the applications in this domain, qualities which are not characteristic of many commercially-available implementations. We expect to leverage recommendations from CTO research into SOA performance and governance. See Ref 10 for more information on the details of other ECAS templates.

4.3 Distributed, centralized context processing For an ECAS system, environmental and context processing can be distributed or centralized or can be implemented as a hybrid of the two. Distributed context processing is more scalable in that as the size of the institution or facility it is being applied grows, the capability of the distributed network of context processing nodes also grows.
Distributed processing requires that what can be very sensitive data be passed out to the edge of the network or close to the edge of the network, thereby requiring more stringent security, access control, and authentication into devices or nodes which contain the sensitive root data files. Furthermore, while a context processing node may have ready access to data in its vicinity, it may have to collaborate with other nodes to ascertain global context.

Some workflow systems require tight control loops and thus must have a certain amount of processing done at the edge of the ECAS system. For example, if a hospital intrusion system that relies on video processing and must automatically initiate functions in near real-time (such as locking doors), this processing should be done in a distributed manner at the edge of the network and reported to the central system. Survivability is another reason for distributed control, if the healthcare entity has multiple sites.

Centralized control offers the advantages of simpler system implementation and security control, at the cost of increased network bandwidth.

If the system evolves towards a generic infrastructure, then the evolutionary nature of this process will likely result in a hybrid solution.

4.4 Sensor solutions As shown in Figure 4-3, there is a wide variety of sensors; however only subsets of these have evolved to the cost points and utility that allows them to be used in business applications. Sensors for physical security and for heating and ventilation monitoring are commonly in use to enhance operational efficiency and effectiveness. Others, such as bio-toxin or explosive elements detectors, have well established niche application areas.
Wireless signal monitoring can be used to provide location and identity information, which are key technologies for healthcare. Combining application-appropriate sets of these inputs, and integrating them into workflow, are the next steps in ECAS
application development.

Sensors detect some aspect of the physical environment and convert that aspect into an electrical analog which can be transmitted. They may provide a status - e.g.
door Nortel Confidential 54 of 226 open/door closed - or may provide a measurement - temperature is 273.6 degrees Kelvin - and may provide data continuously or only when a threshold or trigger point is crossed.
Sensors may be large or small, cheap or expensive and can include existing equipment plus a communications port.

What Can Be Sensed??
,- ---- - ---- __ ----- ---- ---- --- -Sensed element Examples > Sound > Voices, mechanical sounds, sounds from movemeht > Fence vibrations, ground vibrations from intrude > Vibration inadvertent interadion, > Motion sensors (using technologies below), contact > Movement -~-~ openings, closings E.g. on Gates, Entry points > Video surveillance (manual or automatic analysis, photo->Visiblelight~`-~ beamdisruption > Infra-red II ht--~--~ >~deo surveillance (manual or automatic analysis, photo-i g beam disruption, changes in reflected energy, self-radiation (hot persons, objects) >Wireless signals--.--__ _> > Interaction of objects, personnel with RF fields (quasi-radar or interferometric), active RF emissions > Mass/weight/pressure-1 (inadvertent/clandestine or deliberate/IFF) > Ground perimeter pressure sensors for personnel, objects > Chemicals ----------- with significant mass, matching mass to expected mass Chemical trace analysis, explosives detection >
BIOtOXIn > Airbome, surface bacteria, virus sensing > Hard radiation '> Geiger counter/detection of nuclear decay, hidden object sensing (X-ray, nuclear scanners) > Liquids/fluids/water > Fluid sensorslfloats, humidity sensing > Hazardous gas detection (e.g. H25 sensor, CO sensor or ! > Gases, vapours sensors for more problematic gases) `----------------- ----------------- ------- -------Figure 4-3 What can be sensed?

Sensors detecting and monitoring the condition of patients are common in the hospital environment, and are expanding to home and community healthcare. For example, remote wireless continual monitoring of blood sugar or heart rate can now be done. At present these sensor systems stand alone from the general application of ECAS, however in the future we expect more interactions. For example, blood pressure could be correlated with location, or respiration with air quality.

4.4.1.1 Sensor Access Networks Sensors may be wired or wireless.

Wireless access methods included WLAN, ZigBee, and Bluetooth. WLAN is gaining strong acceptance for location systems because the infrastructure is already being deployed for communications. Location tags currently contained embedded motion sensors to activate the tags and communications protocols. Lighter weight protocols such as ZigBee (IEEE 802.15.4) have emerged for other sensors because of the requirement for low-cost and low power, coupled with the fact that sensors do not always require a full communications protocol stack. ZigBee networks, however, are not currently in common use in hospitals. Another method of wireless access, for example for body monitoring sensors, is via Bluetooth or proprietary wireless connections to a wired or wireless terminal. The terminal may contain storage and processing, and has a connection to the wider network. This method is becoming important for home and outpatient care.

Nortel Confidential 55 of 226 Simple example of wired sensors networks are smoke alarms and door alarms. In some cases, sensors are integrated with communications devices such as access points or with other entities. Such networks have had only limited deployment in hospitals, mainly around location-base applications and some implementation for emergency services.
The individual sensors may have an IP address and stack, or just the edge gateway may have one with a local addressing scheme. Currently in healthcare the location badges typically include an IP address and stack.

4.4.1.2 Sensor networking and conversion of data to information Sensor data in its raw form will not always be useful to the ECAS system. Pre-processing must be done in the sensors gateways, even prior to input into an ECAS
template. "Data fusion" is the process of combining and correlating sensor data and processing it where needed, to provide meaningful information to the system.

This pre-processing can occur in a sensor gateway at the edge of the network.
4.4.1.3 Value of multiple senses The value of the ECAS solution is that it can detect and adapt responses to anticipated situations. Sensors provide ECAS applications with the ability to measure, track, and communicate with the world around us. The utility of an application should increase as it uses more context and environmental inputs and outputs. Combining RFID (what), location (where), sensors (characteristics about an object or its environment), and network intelligence with business processes and applications brings value that is more that the sum of its parts, as the cartoon in Figure 4-4 illustrates. Whilst each person in this cartoon could gather a piece of the data required to identify the situation (in this case the presence of an elephant), none can identify it on their own. For instance one person would say "I am touching a smooth hard surface", another " I appear to be standing on something 9 feet tall and I am touching a moving warm leathery surface", or "I
am touching something like an enormous leathery fire hose that moves and is near that reported smooth hard surface". It is only by combining the data that the useful information can be deduced - this is an elephant.

In our scenarios the cartoon people are replaced by various sensor and location technologies that by themselves produce data but in combination allow the derivation of information.

Nortel Confidential 56 of 226 Figure 4-4 Value of multiple senses.

4.5 Functional requirements and impact on solution selection Categories of functional requirements that impact solution selection include - Common Functional Infrastructure - Agility - Clinical Grade Section 6 and Section 7 describe healthcare applications and the requirements they place on ECAS; this section describes the considerations determining the impact of those requirements on the solution.

4.5.1 Common Functional Infrastructure To leverage the ECAS architecture the solution selected should contain common, reusable functional elements that provide interfaces to the top of the application stack.
4.5.2 Agility in Information Infrastructure and Workflow Both the healthcare environment and ECAS solution are in continual state of flux. The drive for improve care and efficiency, new regulatory requirements, and the resulting new administrative policies causes continual changes in policy and workflow.
Therefore policies and workflows must be easily adapted within the system. ECAS
component technology is also changing rapidly. This is the lesser of the two impacts, but Nortel Confidential 57 of 226 nevertheless an important consideration at this point in time as healthcare rapidly enters the information age.

Thus as the application requirements are examined, the solution architecture must seek appropriate demarcation points between the applications and base technologies that will provide maximum flexibility with minimal system complexity. This is a systems trade off. The flexibility must provide system managers, who will not necessarily be IT
experts, with the ability to quickly change workflow. The system should also allow for rapid integration of new ECAS technologies and adjacent ECAS information systems by experts.

4.5.3 Clinical Grade impacts Section 3.2.6 described Clinical Grade attributes and how a general ECAS
solution might aid in achieving these attributes. The following list describes the influence of these attributes on a more healthcare-specific ECAS solution, targeting a broadly applicable hospital infrastructure: -1) Availability - High impact. ECAS availability must be higher than current Enterprise grade. Potentially increased cost.
2) Security - Moderate impact. Solutions exist but must be integrated.
3) Quality of Service and guaranteed SLAs - High impact. Repeatable solutions do not exist, and the impact of guaranteed SLAs on the business process is extensive.
4) Pervasive Coverage - High impact. This does not currently exist without significant systems engineering, which has never been done to the extent required.
5) Mobility and Session Adaptation - High to moderate impact. Solutions are emerging but there are substantial hurdles to widespread deployment with ease-of-use. Context must be known to adapt sessions appropriately.
6) Transaction Integrity - Moderate impact. Solutions exist. The ECAS solution can enhance existing solutions if design appropriately.
7) Non-repudiation - High impact. Few solutions exist that are repeatable and implementable for a widespread ECAS system. ECAS may help solve this problem.
8) Ability to evolve - High impact. Points to a compartmentalized and/or near-standardized ECAS system.
9) Human System Interaction - ease-of-use and consistency - High impact.
ECAS components must be selected to meet this criteria, and combined with expert human interface design.

10) Workflow engaged - High to moderate impact. Workflow management systems are available but not widely deployed. However, a recent increase in industry activity will help address this portion of the solution. For example, BEPL standards and associated workflow development tools. ECAS
components must interface easily to workflow systems and tools.

Nortel Confidential 58 of 226 A comparison of the quantitative requirements for three applications (equipment tracking, clinical point-of-care, and codes calls for Blue and Adam) is shown in Table 7-2. Note there are cross impacts of the functional requirements onto the solutions for each application set. For example, the same infrastructure will be use for all applications; so while services can be given higher priority for improved performance, the requirements of mission critical applications such as code calls still dictates a high degree of reliability for all network infrastructure.

4.6 Fitness-for-use requirements and impact on solution selection `Fitness-for-use' is a measure of how well the ECAS solution for healthcare meets the overall application requirements, and conversely whether or not the ECAS
system actually improves hospital operations. Fitness-for-use was identified as an important consideration when assessing solution alternatives because of the extensive list of application and system requirements. We wish to ensure that even if all the requirements are met, an over-arching viewpoint that determines that if the ECAS system is worthwhile is included in the assessment.

The final measure of success of the ECAS solution for healthcare is the degree of clinician acceptance. Efficiency and improved care will lead to clinician acceptance.
Nortel Confidential 59 of 226 Solution composition This section describes the development for the ECAS solution and its specific adaptations to healthcare.

5.1 Component parts Components of a healthcare ECAS solution are listed below. This list cannot be exhaustive since the ECAS concept can apply to so many existing and emerging purposes and applications. These are the components required to allow the system to meet most of the known requirements. Each application can use several information inputs and outputs and interact with several ECAS technologies.

Physical inputs 1. Location and proximity - generally in-building but may extend to the WLAN
- Where are you? - Physical location against set of coordinate points - Coordinate points may be latitude, longitude, location reference to a building, or a room or may be proximity to another object - May inherently include identity 2. Identification - may include Class 1 to 4 RFID tags as well as being associated with location and proximity discrimination, cell phones and other mobile devices with ID, SSID and many other methods - Who/what are you? - Identification at an appropriate level of trust/confidence/
granularity - May include a name or other cross-referenced ID in a local or global database 3. Sensing - includes analog sensors to detect physical environmental quantities, for example, heat or pressure - What is your/its situation/environment? - Identification of a physical parameter at a location - Can be any physical parameter including heat/temperature, light, pressure, gas/chemical, liquids/humidity, hard radiation, electromagnetic signal strength, acoustics, etc. etc.
- Biometrics, video and other inputs to the authentication process 4. Medical Instruments - most new medical instruments that contain electronics and/or computing now have the capability of networking. This means a wide variety of additional patient data on the network, with mission critical requirements, that interface to other ECAS systems.

Information inputs 1) Entity lists - Doctors, nurses, medical equipment 2) Scheduling information - personal, shift/roles, equipment, maintenance 3) Policy 4) AAA information for entities Nortel Confidential 61 of 226 Adaptation functions 1. To adapt environmental and context I/O to standardized formats for use within broader use within the system.

Processing functions 2. A coordination and processing function, associated with a set of policies, which adapts the behavior of the network 3. Means for applying the decisions back into relevant environments and voice, data communications 4. Rules Engines - Self-Learning entities are a future requirement in need of research, as the rules engines will be difficult to manage for a system with many inputs Communications Networks and Systems 1. Communications infrastructure 2. Communications status - Presence 3. Device capabilities 5.2 Network Infrastructure This section is primarily focused on the hospital communications network, especially a hospital communications network with an ability to deliver advanced clinical services.
5.2.1 Communications Infrastructure The hospital communications infrastructure includes a voice network and a data network, as well several small adjunct systems. Hospital networks are evolving from PBX
and point-solution networks to converged voice, data and multimedia networks that are capable of providing a wide variety of services. Initially these services will be incremental improvements on existing services, with opportunities for multimedia and collaborative services. The evolution toward a converged communications network creates more opportunities for with other ECAS solution components to provide workflow solutions.

Voice Network Hospital voice networks based on traditional PBX's have the potential for only limited ECAS integration via the PBX Computer Telephone Integration interfaces.

Data Network The data network within the building would generally be a typical Enterprise data network, in some cases built-out to higher capacity to support PACS.

Converged Network Leading-edge hospitals are migrating to a converged IP network, using VoIP
soft switches to provide voice services. This provides more opportunity for ECAS

Nortel Confidential 62 of 226 applications, given the more open access for the voice switch and potential variety of communication sessions via SIP. Very few hospitals are integrating multi-media capable communication switching systems such as MCS.

Regional and Metro Networks Many hospitals have regional operating entities, for example the Ottawa Hospital and the Winnipeg regional administration, or the University health networks in Montreal and Toronto. In the United States, regional private or research health networks often fall under common administration. Thus, there is usually also an inter-hospital metropolitan network. This network may consist of high capacity fiber links between hospital and data centers, for the purposes of data storage, PACS and health records systems, disaster recovery, voice communications, etc.

The hospital network also has communication interfaces to EMS and city services.
Video Conferencing and Telemedicine Video conferencing and telemedicine systems requiring higher resolution and/or time-sensitive performance are usually specialized, rather than operating on the generic hospital communications infrastructure.

Wireless Network Nurses at many institutions either rely on or used to rely on wireless phones such as Companion, but most hospitals are now deploying WLAN for voice and data point-of-care applications. The voice sets integrate with, for example, nurse call systems which send informative text to the WLAN telephone set as the nurse is being called.

Physicians commonly use cell phones or smart phones for scheduling and contact in the WAN.

Paing Legacy paging systems are gradually being replaced or integrated with VoIP, WLAN, and cellular data system.

Nurse Call Network Legacy nurse call networks were hard wired to, for example, the alarm push-button or pull-cord at the patient's side. An independent system would control the distribution or the alarms to a central monitoring station where the nurse would be manually paged or dispatched. In most modern hospitals, this archaic system is rapidly being replaced by nurse call systems that are integrated with the voice switching system and WLAN.
Centralized monitoring is still done via a computer terminal, but the process has become more automated.

Equipment Monitoring Networks While most new hospital equipment comes with Ethernet connections, some equipment uses legacy 802.11 standards for point-to-point communications (e.g. wireless EKG
monitors). Equipment such as infusion pumps not contain or have a card slot for 802.11 Nortel Confidential 63 of 226 WLAN cards. Bluetooth is available in some cases but not prevalent; the potential RF
interference issues between WLAN and Bluetooth have not been resolved.

Clinical and VPN Access Satellite clinics access the core hospital network via TI, DSL, or VPN. For remote clinicians, such as outpatient nurses, personal VPN access over the cellular data network can be used.

5.2.2 Hospital Access Network Figure 5-1 show a portion of the hospital access network specifically to provide wired and wireless Point of Care access, with the ECAS additions highlighted. Sensor access varies from wired Ethernet, to WLAN, to propriety UWB location system signals (i.e. the UWB tags, shown beside the `+' signs in the figure). In all cases the sensors and/or location system meet at an IP edge.

Scalability in wireless access may become an issue, as equipment tagging applications grow. These tags may use proprietary, 802.11, or other standardized access methods.
For 802.11 in particular, where the access network may be used for many other applications including VoIP, system engineering must be done as the number of tags grows to ensure that Quality of Service (QoS) and Class of Service (CoS) is maintained.
Wired access in a hospital can be expensive, due to the need for a sterile environment.
Not shown in the figure is wide-area mobile access for physician on call or out-patient/home care nursing staff or the other organization such as Emergency Medical Services (EMS). Extending the ECAS solution has a significant impact on the architecture, since more applications must be adapted, more context information is potentially available (e.g. wide area location), and more workflows keying on roles and scheduling are likely. As well, the access network in the wide area is somewhat beyond the span of control of hospital network administrators.

When examining Figure 5-1 one is struck by the overall complexity of the solution. It must be borne in mind that the parts of the solution shown in Figure 5-1 that are not highlighted would be pre-existing parts of fully functional pre-ECAS Point of care solution, which itself had been built up in stages. Only the highlighted areas have to be added, along with the context processing servers in the core HIS, HCIS. Even these components can be phased in, for instance starting with a location capability and adding sensors later.

Nortel Confidential 64 of 226 Figure 5-1 Hospital access network showing possible ECAS components.
5.2.3 Wireless and WLAN
The access picture above emphasizes that mobile applications and WLAN are currently highly important within a healthcare ECAS system. In addition to basic communications, a WLAN can enable ECAS components such as location, video monitoring, and sensors or sensor gateways.

5.3 Physicallnputs This section will provide an overview of potential physical inputs components for a healthcare ECAS and some associated issues. Further more detailed information can be obtains in the internal reports referenced in Ref 11, 12 and 13.

5.3.1 Location technologies, precision, accuracy and ubiquity Locations systems for indoor use range in precision from centimeters to 10m.
The percent of measurement samples within a given precision giving rise to the system accuracy is also a major consideration to ECAS application requirements.
Certain WLAN systems tested, for example, show a precision and accuracy of 6 meter precision for a 90% accuracy level. This is sufficient for some healthcare applications, such as coarse equipment tracking and determining which ward a clinician is in, but not others, for example clinician-terminal association. For these applications a high precision location system or a proximity system may be more suitable - and there are several trade-offs, benefits and drawbacks to consider when selecting which way to proceed.
Latency, coverage, and security are also important to varying degree for different applications.
Implicitly most location systems include an identification component; however there are examples where this need not be true. Thermal or video imaging systems, for example, could alert monitoring system to the location of a general object. In healthcare, these are Nortel Confidential 65 of 226 not likely to be near-term components for the ECAS system except in very specialized circumstances or in specific areas of the hospital. They are relevant to security applications.

WLAN, RFID or other wireless tags can also store information about prior life -i.e. they can contain elements of sensor behavior. Most WLAN tags now contain motion sensors to (optionally) activate them and also have actuators like flashing light and sounds.
Integration of humidity sensors has been proposed for medical supply inventory applications.

Outdoor locations systems and integration with indoor systems do have healthcare applications, but will not be discussed in detail hear. Outdoor alternatives include Assisted Global Positioning System (A-GPS), and cellular triangulation, which is currently used for 911.

Sample of tags used in location systems are shown in Figure 5-2. Location or proximity systems for in-building healthcare include:

WLAN
WLAN tags are typically on the order of 2x3 inches, with system accuracies on the order of less that 5m. The AeroScout tag in Figure 5-2 is one such example; Ekahau is currently a partner with Nortel and provide similar tags. Wireless computing devices (PDA, tablets) can also be located via the use of soft clients or passive detection. The accuracy of WLAN location technology is sufficient for coarse equipment tracking and inventory applications, a common demand in healthcare. WLAN location implementations do not require additional infrastructure initially, i.e. above that used for communications, however there are concerns about the scalability of this approach. The calibration required to configure these systems is also an issue. Battery life of the tags is limited by the 802.11 protocols and IP stack in the tags.

WLAN tags currently are used for high value inventory items, largely due to their relatively high cost, which is on the order of $50 or less and dropping. The range or these systems make them suitable to track equipment moving throughout the hospital or campus.

WLAN systems are based on RF fingerprinting.
UWB
Ultra-wide band systems offer increased accuracy, down to tens of centimeters, but at the cost of additional wireless infrastructure. UWB tags from a Nortel partner, Multi-Spectral Systems Incorporated, are shown in the upper left of Figure 5-2.
These can be as small as less than a cubic inch in volume and also, while not shown, an employee badge shaped tag is available both with and without a biometric scanner (for fingerprints). The accuracy of UWB tags permits an expanded range of applications, such as associating a phone with a person near it.

Nortel Confidential 66 of 226 UWB systems are based on time-difference multi-angulation or time-difference-of-arrival.
Optical and acoustic Optical (infrared) systems are legacy systems. Acoustic systems have the advantage of no RF interference, which is extremely important for hospitals - but do not have widespread acceptance.

RFID & Proximity Proximity solutions are based on various classes of RFID. The card and keys in Figure 5-2 are examples of RFID tags. Passive RFID tags are used for drug tracking and security badges in hospitals. RFID tags have the advantage of no battery (passive tags -except when activated) or low power consumption (battery powered Class ll-IV
tags).
Their range can vary significantly, but for passive tags likely to be used in hospitals that range is on the order of a few meters. The passive RFID tags require a reader nearby, which may be incorporated in a communications device such as an IP phone.
Thus, the RFID tags could be used to detect the proximity of owner to the device or to configure the device for the owner of the tag.

The low cost and short range of passive RFID tags make them attractive for higher quantity, low value inventory applications.

RFIDs used unlicensed RF frequencies for their operation, and are typically activated in a transponder-like manner by an RF activation and powering signal.

Figure 5-2 Location and proximity tags.

Nortel Confidential 67 of 226 5.3.2 Sensors and sensor networking 5.3.2.1 Sensors Sensors in use or anticipated for use in hospitals for an ECAS system will be described here. Sensing systems usually include a geographical and time component within the monitoring system, although there are exceptions. (e.g. a group of sensors could theoretically determine its own location, or time reference in relation to other events) Patient Monitoring Sensors for a healthcare ECAS system include many that are also applicable of other ECAS applications, but in addition, a wide variety of patient monitoring sensor. Currently these sensors are deployed in closed monitoring systems, for operational and privacy reasons. Although this is unlikely to change quickly, the medical instruments that control and monitor the sensor are rapidly becoming networked and have the ability to be monitored and control via management systems running on a common IP infrastructure. This can lead to new applications; for example a nurse call system offered by Emergin detects irregular heartbeats and sends video of the Electrocardiogram (ECG) signal to the responsible nurse. In the ECAS system, the `responsible nurse' can be determined by the current context of each nurse.

In summary, while sensor applicable to healthcare are in the near-term are likely to be similar in scope to other fields, in future the addition of the human condition can lead to many other potential applications in healthcare. Since the primary mission of hospitals is patient care, these sensors should be integrated with the healthcare ECAS system.

Building The include door alarms, fire, bio-toxins, and gas.
Inventory Including heat, humidity, and light. These are important for drug and medical supplies such as stents. A recent example given by a location/RFID company demonstrated how a supply of stents did not have to be thrown out after a power failure, because sensor and time measurements indicated that humidity and temperature thresholds were not exceeded.

Securi These include door alarms, motion sensors, and biometrics for building (e.g.
video/facial) and device (e.g. fingerprint) security Associated actuator pairing may exist for each sensor. For example, a door lock paired with a door alarm.

Nortel Confidential 68 of 226 5.3.2.2 Sensor Networking In addition to the physical network, the term `sensor networking' encompasses the network functions needed to create the ECAS solution. These functions include data coordination, time-stamping or otherwise referencing data, the application of inter-sensor system protocols, decision processes to translate combinational data into decisions, and the creation of management information or actions recognizable and relevant to the user.
A simplified model of a sensor network is shown in Figure 5-3. The sensor network contributes an awareness of multiple environments into ECAS but the data flow and processes of deduction of information from the raw sensor data need to be considered carefully, since otherwise either excessive redundant/valueless data could flood the network or too mach data could be rejected causing less than optimum information to be generated from that data, giving ECAS a non-ideal view into these environments.

Policy <Engine SensorlRFlD~ased ~~~ wa Evolved Apptications (SAS) n communications Data and Decisi ak~ cD 3 Data flow, products, T 0 Interactions workflow, and IT
0 systems Relational database Feedback -collection and filtering adaptation, ur Network sensor control Collection, Filtering ~C-Lls N finro~ k?
Sensors, 'r ~ ,y actuators, locators & RFID

Figure 5-3 Sensor network architecture- simplified view.
Access Network The optional access network contains raw information consisting of time-critical and non-time-critical information, real-time and non-real-time information, high speed and low speed information, parametric and non-parametric/deterministic information. This drives multiple different bandwidths and delivery pipe solutions as function of environment, market segment, and application.

In hospitals, the access network will be as previously described in Section 5.2.2 Nortel Confidential 69 of 226 Collection, Filterin~
This layer provides primary (non-lossy) data reduction, some data coordination, and decision making in applications where responsivity is more important than inter-family coordination. Security, data validation, and access network validation are functions that may also be performed here.

It is unclear whether or not the collection and filtering layer will play a significant role in hospitals since we first need to understand the quantitative aspects of the applications using the data, including their frequency of use, which has still to be determined by examination of future clinical workflows. The closed system and smaller scale required for many applications may allow for transmission of most sensory data through the network. An exception may be found in RFID and location systems as they scale significantly.

Network Raw data in the core network may produce excessive transactions and bandwidth requirements.

It is likely that raw sensor data will be restricted to subnets within that hospital, and propagated to other information system in a processed form. This necessitates a hybrid distributed-centralized solution for collection and filtering.

Sensor/RFID-base Data Mining and Decision Making This entity includes sensor data coordination including time-stamped data, application of sophisticated inter-family protocols, decision processes to translate combinational data into decisions, and actions recognizable in the user world. It is the brains behind the operation.

In a hospital, this layer would manifest itself in the form of workflow templates and reusable application components.

Gateway to Communications & Other systems The gateway allows information and commands to be exchanged in a common format between the decision making engines and the other systems.

In hospital applications, the communications system would provide near real-time data including presence and device type. Ideally it would be a multimedia system that would also provides session types and preferences. Commands via the gateway can cause actions in the other systems, for example initiating a communications session between clinicians.

Feedback A feedback loop is included to modify sensor capabilities or trigger actuators. In a hospital, for example, closed loop control might focus security cameras on an event, or lock doors.

Nortel Confidential 70 of 226 Figure 5-4 is an abstracted view of an ECAS healthcare system. At the sensor layer, elements like WLAN, RFID, and video are gradually being integrated with the overall ECAS system. New elements include medical instrumentation, toxin sensors, biometric readers, actuators, robots or haptic sensors, and smart building sensors.
Sensor and RFID
gateway functions (e.g. collection, filtering, and address translation) may be incorporated into edge communications switches. The base functional components such as the location server, `meds' server', and future biometric authenticators can be instantiated as ECAS templates, overseen by the workflow systems and associated management tools.
SOA/XML interfaces can be viewed as an Enterprise Services Bus. Workflow elements drive user applications at the top of the diagram.

Figure 5-4 Layered view of hospital ECAS architecture.
The model consists of the following layers:

1) Uses and user agents - the users of the workflow system. Currently the users are people in many specific roles. They must access many disparate computer applications to perform their functions. The computer systems are not linked to the environment in real-time and perform each application on one devices.. In the future machines and intelligent systems also become clients. Clients are linked to applications that span more of their entire workflow or to applications that cooperate for perform workflow functions more easily on behalf of the client.
The clients will work with multiple devices in the future, and may be machine artificial intelligent entities operating autonomic workflow processes. These are known as agents.

Nortel Confidential 71 of 226 2) Applications - provides the user interface and manipulate workflow data entities on behalf of the client. Each application supports multiple devices or form factors.
Currently applications generally support on type of device or form factor (e.g.. the personal computer or a PDA). Applications communicate directly with sensor systems or their application gateways. In the future, applications will need to adapt interfaces to multiple devices.

3) Workflow System - provides the horizontal and diagonal integration between applications and sensor systems, the "middleware". Currently workflow linkages exist on an ad hoc basis and clients are often force to access many systems to perform one task. Workflow systems are beginning to be integrated with communications systems. In the future, applications data exchanges and control will be easier to implement and modify due to evolving interfaces and workflow process descriptors like SOAP and BPEL. Proprietary, custom interfaces and workflow descriptions will be replaced by commonly understood terms that are easier for a wider community to manipulate, that have more business rather than technical expertise. The workflow middleware will become more pervasive and allow applications and environmental input to be matched to client workflow.
The workflow exchanges process data and messaging for event control and management with the sensor systems. Workflow processes should be customizable per end user, group, organization, etc. and able to adapt quickly to new processes. Supporting databases provide policy and analytic rules.

4) Sensor System Virtualization - this is where the ECAS templates would reside.
Common representations of the data would be provided to the upper layers of the model. The layer would also do processing and amalgamation of lower-level data.

5) Sensor Systems - the sensor systems provides the management and control for the sensor and actuator sets, which are in minimally-processed form. An example is a location system. Via interfaces, the communications system and supporting IT
systems (databases, storage, and backup) form a part of each sensor system. In the future, more sensor systems appear and virtualization functions allow like sensor systems to appear as one to the workflow system layer. For example, location data from enterprise (e.g. WLAN) or carrier (e.g. cellular) can be abstracted to location with coordinates and a resolution to the higher layer functions.

6) Edge Functions - sensor collection, processing, and encapsulation functions that are best performed at the edge of the IP network. Currently a limited set of functions are done at the edge, mainly IP encapsulation and aggregation. It the function, many functions may be done at the edge in common network elements including QoS processing, priority tagging, real-time control, filtering, and content pre-processing. Key network architecture issues for Nortel are: what are these functions, and do they justify new network elements such as sensor gateways? Are they integrated within existing network elements? Or will they be stand-alone systems not related to communications network elements?

Nortel Confidential 72 of 226 7) Sensors and actuators - the highly distributed elements that measure and interact with the environment. RFID tags for drug and radio ID location tags (WLAN, UWB RFID) are current examples emerging in healthcare. Many more exist and may be gradually accepted by the medical community, with increased real-world interaction, geographic coverage, and pervasiveness. These include increasingly interfaces to medical instruments, which are now all being network. More centralized or comprehensive monitoring systems for medical instruments are emerging, however because of the direct impact on patient welfare integration and acceptance of automation into workflow will be a slow process. Toxin sensors including gas, radiation, and bio-toxin sensor will gradually become wider spread, as cost points and practicality improve driven by military development. In particular, it expected that location technology for personal and assets tracking and RFDI tags for drug tracking will become ubiquitously deployed throughout the healthcare industry and a will be highly integration with client workflow.

As the workflow becomes more and more engaged with and dependent on the ECAS
network, the need for Clinical Grade quality of the overall system becomes more and more apparent.

Figure 5-5 shows a hospital network solution with ECAS components added. The new components are show shaded. The future network architecture enables the system to become workflow engaged, by the introduction of a middleware layer. The evolution to this architecture will be gradual and piece-meal, not instantaneous. It is envisioned to contained ECAS templates and based on an Enterprise Services Bus-like architecture.
There is a business opportunity apparent in the development of the middleware layer, in the form of professional services and system's integration. The middleware layer allows the user (person or machine) to access one gateway or portal application to perform workflow functions, and is designed to be highly adaptive and flexible via the use of XML-based interfaces. New servers have been added for the many new sensors and actuators that have been added to the physical layer. There may be new network devices (or functionality) to perform switching based on sensor context or content at the server or edge-side of the network. For example, Cisco has an RFID blade that eliminates duplication RFID reads. The IP edge is still at various points throughout the network, however richer edge functions have been added that exist in specialized sensor gateways or embedded in edge network devices. Wireless access for the sensors has increased, and more interaction with the ECAS WAN is occurring. New databases, and the required backup and redundancy systems, have been added to provide for data mining and biometric identity. The network must be `clinical grade' because the ECAS
network has become an integral part of hospital operations. However, it will be some time before the network evolves to support the most mission-critical systems, such as life-support.

See reference [10] for more information on how the components fit into the ECAS
system architecture.

Nortel Confidential 73 of 226 _.. __._.._~_____~_. _. _.__._....~ ...._ ... ._..........._... ._.._ _.__._... _.. __.__.... .. . .._.__. __ , -I }
O
cu ' Y W
c~~
E U) o < V a E U 2 _ 06 (2 O O W N W 9 c~ a E -o ui m E
y ar ; cB o m O(1) g o (n E

(D
(o rn o y p > > Q o` N
c =
W fn o O
~ - ~ y U
j O Q1 w . U) U) 0 ~~. -O O . _.. _.. _.
~
m N T
N i C' q m w H ~ Ã I V U [ A .~ ~ ...._.
~ ~\ m (n I
-I Q f 2 2 ~~
o a c ; n ~ o 0 U) pL,~~l UOE
Q - c >
aa a ~ ~ Q O ~ ~
~ ~. . vO o I ~-~ ~
U
(h -0 d Y

o g a ~n . LL M
~ NN iam;i p a', ~ O 0 -2 (D ~
O N :!-:_ O E a) ' rn 1 0_ '. m C6 Q. X~. W~~. W ~
C , ~ . ..._ . _._ ) ~ ~

Z j. ~ J O w cn O "l . C a> O
O Q ~ N ~6 . . ,.._._. ...._.__ i U) 3 Q n O C
a ~Z3N Q, aL
~ u r ~ o ~. ~ ~ a cn o o~
o J Q
I~~~
' 0 Q ~ ~~~ ~ ~ ............
. I ~ ~ _ . ,.. z U Q
it i JK ~
It oa) oaNi ~.và . V .. v/
-`-i ~ c) o L ,i -o O 0 E; x~
........
"` ~ L
0 N ~ .~ ~ 0 y U) 0 ~

~ U = ~ Q1 C~
w Figure 5-5 Hospital reference model with ECAS system.

Nortel Confidential 74 of 226 Figure 5-6 shows a possible future mapping of new ECAS elements onto Nortel's reference architecture. On the left of the figure, various sensors and their associated gateways or collector network elements have been added. At the services edge, an ECAS processing function has been added, which could be done via XML
constructs. A
virtualization function, which combines inputs (outputs) from (to) various sensors (actuators), is included in the service core, enabling new applications thru open APIs and standard data descriptors. The evolution to the future reference architecture is likely to be slow and fragmented, evolving as various edge sensors, middleware, and applications develop.

Figure 5-6 Mapping of ECAS onto Nortel's reference architecture.

5.3.2.3 Geographically Distributed Sensor Networks Thus far we have focused on ECAS solutions for hospitals. Healthcare solutions increasingly are spanniug a wider geographic area, even within one institution. For example:

1) Healthcare providers in the United Sates have been amalgamating within metros to forrn multi-hospital entities Nortel Confidential 75 of 226 2) Increased competitive pressure and privatization force specialization and optimal use of distributed resources, whether they are local or remote. Radiologists are a prime example.

3) There has been an increased emphasis on home and community health, both for reasons of necessity and due to opportunities presented by technology. An aging population and overfilled hospitals create a need for it, and increasingly pervasive broadband networks and mobile device capabilities create an opportunity.

Figure 5-7 shows how the distribution of sensor network functions can vary with (non-clinical) application. In healthcare scenarios, the applications can vary as widely as those shown in the figure. A multi-hospital campus would be similar in geographic scope to a seaport, and a community healthcare or EMS application would be similar in scope (metro or national) to the homeland security example.

> D = Data > Global ra Mining, c D o Decision- > National ~ A,B ~ ;
making ~ Filtered 3. = d Action conclusions, N CD
taking > historical data, A B 0 Statel emergency response data, Sensors C,D~ [
Province input to/From { ~#f Homeland A,B
C Security, etc.
Filtered conclusions, Sensors C,D
> historical data only, 'A .
Relational } s > Regional e.g.statistic5aiioWing ;,B
epidemic control C,D in IT rooms C,D~
Database or 1-3locations Sensors ~ 4 ~ t E
within PA zone7 A B
In-Area > A,B, Area some C,D
C
,D j~~
Sensors Sensors A B y~
>
g B = Filterin C,D in lT room or Sensors C p O
> Local 1-3locatrons Sensors wi N
thln hospital? Facility ent A,B fD fC
C:loset4 A,B gatehouse ~ f r ID
Sensrs A,B, some C.D
Sensors C,D ,3..
> A = Sensors > Immediate A,B
Collection vicinity ~nsors Sensors Sensors a o30 Hospital'* Seaport Homeland m Q
amat Smart building -4thermal, light, access control, air quality, Security $ k ~ m physical monitoring including material/personnel location, theft- o ~ 3 control y a ~
Figure 5-7 Network dimensioning varies with application.

5.4 Communications Status Unlike point sensor solutions, the ECAS solution also takes into account other information in its decision process. Of primary interest to Nortel is communications status, including:

Nortel Confidential 76 of 226 Communications Presence Communications presence is the willingness and ability to communicate. Basic communications presence tells the system if the clinician is online or offline and if he/she is active on the network. Presence can be more sophisticated, such as identifying the current level or type of activity. For example "active in a meeting" or "do not disturb - in operating room." It can also include some of the items below, either processed or in raw form.

Device type & Capabilities Is it a PDA or laptop, and does it have a camera? What state is the device in?
What is the current modus operandi? Clinical mobile devices may require a `privacy' mode.

Bandwidth usage This is important for priority or quality of service requirements.
Service or session type Is a voice, video, or data session in progress? Can it be interrupted for an urgent call, such as a nurse call or emergency code call?

5.5 Entity Status The entity status can be considered from 2 perspectives:
Enti . State Entity state is he state of an entity within a system, where an entity is a machine. For example the state of a medical instrument:
- Is the machine operational?
- Are there any alarms?
- What is its maintenance status?
Entity Presence In the case where a software agent is interacting with a communications system, there are many analogies between "entity state" and "communication presence"; hence the term "entity presence".

5.6 Control architecture ECAS also exerts control over the communication network (for example, to automatically initiate a session between clinicians) and other systems. The control loop is essential to healthcare application for many reasons, relating to the tenets of Clinical Grade networking. Some reasons are:

1) High quality care - without feedback there can be no automated intervention to ensure quality care. For example, the monitoring of air quality can be critical to the health of patients with compromised immune system. Data about this could be sensed and forwarded to either a clinician/member of staff Nortel Confidential 77 of 226 or to an automatic process to allow adjustments of the rate of flow of the filtering system can be made based on measurements of air quality.
2) Emergency systems acknowledgement and physical confirmations - for emergency systems confirmations and adjustments are required to ensure mission critical performance. For example, if a Code Blue call were sent to a select number of clinicians based on location, their response must be confirmed by push-button, voice, video, or location tracking. If not, another clinician or set of clinicians must be called immediately. The life of a patient could depend on it.
3) Efficiency - manual versus automated adjustment of systems.
4) Regulatory auditing - while no specific regulations have been identified at the time of print, open loop solutions applied to clinical systems would likely have more difficulty passing regulatory audits than closed loop systems.
Figure 5-8 shows the control hierarchy in an ECAS hospital system. Control is driven by workflow clients that interact with underlying expert systems via ECAS
templates. With the templates, significant intra-domain data fusion is done by the rule processing.
Messaging between template and expert systems is done via the Enterprise Services Bus.
A layer of interface adaptation, the input-output transfonner, interfaces the execution point to the Enterprise Services Bus. Some domain data fusion also occurs at this layer.
At the bottom of the diagram are the execution and data collection points. The control is top down as shown, however, absent in the figure is the notion of a control loop. This will be described in subsequent figures.

h(IoY C l N Context ~ Decision c~oss domain , ti tlaWfusits~5 Core ECAS 7eniplata Controller 1 Suh-WOrf,(low Drtector Logic o . m 'n . o =n o,E SigrflfcantECAS
.q n w... P L~.
Tei'Yip[ateS U
E
E p _ cl ~[Itain :a a .~ w .c. >

Enterprise Service Bus ~

ECAS Expert EquiPmen MCS Sensor ~. Bio Personnel Resource ULS~ Server A Drs atch Drug So11~Q
.}4~1'StE?i~,s PP~ ~ .
Analyhcs Analyhcs Analytics Seryer Server Quality do7ltain (examples) Maps "' aataf~,5ion InputlOutptit Transformers ECAS lniauts i _ Ex~c~.ition '- ~ --PCJI3tS tvlonrtors ftol ~ ICapahilrhe L-vveRk;Ies~~ilevices r, I SEQta90 (exarriples) Figure 5-8 Hierarchy of ECAS control structures for healthcare.

Nortel Confidential 78 of 226 Whilst this figure appears, and is, complex much of the complexity is in the form of software modules contained within a limited number of server platforms so the incremental complexity in the physical world may be quite low. In addition in the case of a phased roll-out a base set of functions can be achieved without all of the modules being present.

In addition to the hierarchy, a control loop is also required. Figure 5-9 through Figure 5-12 show the `OODA' (Observe, Orient, Decide, Act) control loop and how it can be progressively applied to the ECAS architecture.

The OODA model (Figure 5-9) was developed and is used by the U.S. Department of Defense. It is also being adopted by an increasing number of businesses. The key idea behind the OODA model is to be able to make intelligent decisions and to act upon them faster than could previously be accomplished. Taken to the extreme, the OODA
model leads to the vision of the "real-time enterprise" which is based upon the premise of getting the right information to the right people at the right time with minimal latency.
This leads to faster and better decisions, and enhanced agility and adaptability.

Figure 5-9 The OODA loop Decisions do not necessarily have to be made immediately after new information is available. This is a common misconception. It can be more important to get information ASAP in order to lengthen the time spent analyzing the data and making better decisions.
The OODA model (Observe, Orient, Decide, Act) is fundamentally about increasing speeds so that more intelligent decisions can be made (and acted upon) faster than the competition. Some decisions will automatically be made based on new information triggers. Other decisions require human analysis and experience. Both types are enhanced by the real-time enterprise.

When the OODA model is applied to ECAS, environmental inputs and awareness are the equivalent of "Observe"; context awareness is a critical part of "Orient".
"Decide" and "Act" are straightforward. By linking these functions together into a feedback loop(s), Nortel Confidential 79 of 226 they can be automated and adjust to changing conditions. In addition, policies can be injected into the feedback mechanisms based on Policy Decision Points.

Figure 5-10 Policy injection in the OODA loop and ECAS architecture.

Figure 5-10 shows points where policy could be injected into OODA loop. The stacked representation at the policy injection points indicates that policy can affect different protocol layers of the ECAS systems. For example, a control policy may adjust the reference point for a particular temperature sensor at a lower layer (sensor physical layer), or at a higher layer initiate an emergency call to teams of people in response to a critical set of sensor measurements (workflow layer).

Nortel Confidential 80 of 226 Figure 5-11 The OODA loop and ECAS architectural components.
Figure 5-11 shows the OODA loop with ECAS architectural components. The box in the left of the figure corresponds to Figure 5-4, which is a layered view of the ECAS
architecture in a hospital. A more detailed view is shown in Figure 5-12, where specific functional components are identified.

Figure 5-12 Details of architectural components in OODA.

Nortel Confidential 81 of 226 5.7 Security and authentication architecture impact ECAS for healthcare does not provide but enhances the existing security and authentication architecture. The ECAS solution provides several features that can be used to enhance security and authentication:

Awareness Elements of ECAS provide a situational and environmental awareness that simply was not there before. For example, the tagging and location tracking of medical equipment was not previously commonly implemented. For instance in the past the only indication was a visual confirmation that a wheelchair is leaving the building.

Intelligence Awareness is not sufficient. In the wheelchair example, if the wheelchair leaving the building has been signed out, it is not an alarm condition. Users, in this case Security personnel, only want to see the exceptions; otherwise they will be overwhelmed with ECAS information.

Multi-dimensionality ECAS enables multi-dimensional authentication. For example, if a security RFID
badge enters a room, it is difficult to confirm remotely that it is actually the person who should be associated with the badge that enters the room. However, if his/her location and network activity have also been tracked, along with other contextual information such as their current role, it become much easier to get a degree of confidence that is it or is not that person. For example, if the person is shown to be logged on at home (detected via communications presence) or not on-shift (via the scheduling system), there is a security anomaly.

Actuators The ECAS solution includes actuators, for example to lock door or alert near-by security personnel of an impending theft or abduction.

Many of these items can be incorporated in pre-processing blocks (or ECAS
templates) to feed the higher layer security systems.

5.8 Context processing structures The context processing structures of the ECAS solution are based on the overarching model of Figure 5-13. See Ref 10 for more information.

Self-learning IT is important to the concept for future research that Rules Engines or Decision Blocks must be self-configuring and self-learning, at least to some extent, in the future. The Nortel Confidential 82 of 226 amount of environmental and contextual information to process and complexity of the rules becomes too large scale for human analysis.

In a hospital, this statement is not yet the case, as the ECAS systems would initially be somewhat isolated from each other. The healthcare environment may eventually evolve in the direction of self-learning, but that is in the far future, since the systems are so important to patient well being.

Agents Agents are another important ECAS consideration, i.e. software entities that act of behalf of a human or remote machine. Simple agents may appear in healthcare solutions in the near-term, but decisions that require judgment and/or directly impact patient safety are likely to remain in human control.

P Ui :
Ir'tsit P a r'avr ~ ESIc:'k ~t ~ ~4<:s:~,r L~ISek I't;su; 'Q 5~r ~ QCESSjf~~ 4_J

Kdvr ~<:: CJffe~~aif r. l 3~J:fÃ'Ipf~
ir i F,>=~i:.al cev, r tlutpvt =_. .. r ...~
... .
.
. 4nGpeW-r .........., ,. = .......

B.1:a1=.')r--. ~ "

tI
Figure 5-13. System Data Model. Elements were added in the ECAS Template pattern to handle real time communications/collaboration.

Solution Modularity Besides the key concepts and solutions discussed earlier in this section it is vital that a complex transformative solution such as is being proposed here can be implemented in stages, with each stage being functionally, economically and technically justifiable.
Otherwise the roll-out will proceed to the first stage where this is not the case and will Nortel Confidential 83 of 226 stop there. Hence roll-outs through to the complete solution have to be determined in which every stage is economically, functionally and technically defensible.
This is not covered in depth in this document although the need to do so is recognized and is recommended as future work.

However we can say that several likely roll-out paths exist. One of these, taking seven steps, is included here for illustrative purposes only and would be to: -a) Improve HIS and HCIS support to clinicians by tying a Context Engine into the current databases of the HIS, HCIS and allowing that Context Engine secure selected access to pertinent data to allow better context support of existing clinical applications b) Introduce a coarse location awareness through the use of add-on software-based solutions on to the existing WLAN
c) Introduce a limited suite of location-aware services based upon this coarse location capability and avoiding the need to tackle tricky clinician privacy issues - hence the first applications may be around equipment location and/or tracking d) Increase coupling between the first coarse location capability and some clinical applications being enhanced by the Context Server as appropriate e) Introduce new physical hardware infrastructures - precision location and/or sensors - probably not both at the same time f) Continue to integrate the data from sensors and ever more precise location and tracking data into both routine and emergency clinical applications but at a rate digestible by the clinical staff.
g) Complete a full ECAS deployment Nortel Confidential 84 of 226 6 The nature of healthcare applications The purpose of this section is to look at the type of applications that would be candidates for the attention of ECAS - by setting a baseline view of the general classifications and groupings of applications that exist today. By understanding these characteristics and groupings we can pick a subset of all the applications in such a way that the chosen suite of applications has characteristics representative of a much broader suite of applications, making or necessarily focused work have broader generic significance. Also, understanding the healthcare applications is key to thinking about how to improve them, how ECAS can improve them and where the likely benefits might lie.

As might be expected from a large, complex and diverse sector like healthcare there are a wide range of applications which may exploit or benefit from the application of ECAS. As a result we need to determine some method or methods to group them in terms of characteristics and then look for common themes, functions and needs, both within groups and across groups. Examples are: -a) Location - in-building/outside. In-building can be large building (major hospital) or SMB (cottage hospital, clinic, test lab) so this grouping can split into multiple sub-groups. This document is considering only the in-hospital grouping. This is primarily addressed in Section 6.1 b) Mobility - within one network or across multiple networks, and with static or mobile entities. Mobility within a single building such as a hospital usually only uses a single predominant network with very little mobility between networks. City- wide roaming also predominantly uses one network, the cellular WAN, but mobility between cellular WAN and WLAN becomes important in the cases where the user needs to have enhanced connectivity inside a specific building such as a hospital as well as being mobile across the city. This document focuses on hospitals so will focus mainly on single network mobility. This is primarily addressed in Section 6.2.

c) Routine/emergency - applications can be part of a routine activity or triggered by an unforeseen and usually significantly adverse event, needing a rapid response. Many, perhaps most routine hospital events occur frequently and clinicians become very experienced in them and adept at them. Hence there is a comfort factor that is missing in an emergency event.
Emergency events are also associated with higher levels of personal stress in the participating clinicians, a greater urgency and uncertainty in the clinical outcome and often have very urgent timescales. More details of these and other differences between routine and emergency events will be given in the next section. This is primarily addressed in Section 6.3.

Nortel Confidential 85 of 226 d) Single entity/multiple entity - including team-building. Here an entity may be a person or a machine so multiple entity can be multi-person events, such as clinician-clinician association (e.g. for collaboration), person-machine association (e.g. associating a network-connected medical instrument with a clinician person) or machine-machine association (e.g. a centralized maintenance resource accessing network-connected medical equipment to check their condition, calibration, etc. to ensure their fitness-for-use).

e) Workflow-integrated, workflow-enabling communications and IT
applications, or those outside of clinical workflows. Key groups for analysis here will be clinically-integrated or clinically-enabling (e.g. PoC) or non-clinical, which includes business-enabling (e.g. billing) and safety/integrity related (e.g. theft detection, hazardous situation detection). This is primarily addressed in Section 6.4.

In this package the grouping will be by location into large/small building/outside (cross-metro WAN). We are going to treat large hospitals first, SMB (Clinics, Medical-Dental Buildings, Labs) second, regional health networks third and Wide area outside communications (First responders, clinicians on the move) fourth, and home health fifth.

This document will only be addressing the needs of the large building, in this case a hospital, although the principles and analysis can later be extended into the other areas. We will use a sub-grouping into Routine and Emergency at this stage since routine applications are very different to emergency response ones from the user perspective and emergency response ones can also place significantly different demands upon the ECAS system. In other cases aspects of routine and emergency services may be quite closely related. We will also be examining a broad spectrum of clinical process-enabling and non-clinical applications in both areas.

We are not proposing that Nortel get into the actual Clinical application business itself- there are already many large successful software houses and system integrators such as McKesson, Cerner, Eclipsys, Meditech, etc. in this space and we lack the skill sets and the channels to market to compete against them. But we do know communications and IT far better than they do and this may be the basis of a partnership or other beneficial relationship where we can come from a position of strength.

6.1 Hospitals, clinics, mobile clinician, home healthcare Candidate applications, capabilities and services that may benefit from ECAS
are found across healthcare. They can be broken down by type of location into: -a) Applications within single buildings or campuses - these may be large buildings or campuses, such as major hospitals, or smaller buildings such as Nortel Confidential 86 of 226 medical-dental buildings or small (cottage) hospitals. Hence this group can further break down into sub-groups according to the size and nature of the single building or campus. For this document we are considering the large building/campus (hospital) scenario.

b) Mobile applications for the wide area network addressing the needs of the in-transit clinician or the emergency response worker c) Home healthcare communications - either for a home health worker and a patient at home or for communication with a clinician while they are in their home.

Multiple applications identified, reviewed with customers - solutions enable efficiency, responsivity, convenience, enhance security, safety Figure 6-1 Some Example ECAS Healthcare Application Areas Figure 6-1 provides shows a high level view of potential ECAS application areas across healthcare. This document will only examine the hospitals portion of this figure although it is expected that future documents will cover the other areas.
6.2 Mobility As mentioned earlier clinicians generally have roles which require substantial degrees of mobility. This varies by clinician type and specialty/seniority but also the role will often depend upon the clinician location, although other factors may be involved.
For instance Nortel Confidential 87 of 226 a surgical physician may be involved in a first encounter with a newly-referred patient, pre-treatment investigation and diagnosis/treatment decision-making or a follow up examination in his or her practice office away from the hospital, may do a pre-operation check on the patient or a post-operative assessment in the hospital bed ward but will actually carry out a surgical procedure on the patient in an operating room.
Since the example clinician has multiple patients "in process" at any one time, his or her day may involve all of these stages and other stages of the clinical process he or she specializes in, all in the one day. Hence this clinician would have to be able to send, receive, generate or access information on a routine or emergency basis on any or all of their patients at any point where they are practicing medicine, and has to be able to freely move between the various roles and locations while maintaining this communication.

Different clinicians have different mobility requirements. Some examples are given in Table 6-1 Generic Mobility Requirements For Classes Of Clinicians. From this it can be seen that different classes of clinicians have widely varying generic mobility requirements. Furthermore each sub-class or individual clinician will modify this generic view to create a broader diversity of needs, preferences and requirements based on their specific situation.

Class of Clinicians Intra- lntra-MDB Wide area Home Home hospital (self) (patient) Junior physician - Yes No Some No No hospital Senior physician- Yes Yes Yes Yes No hospital Family practitioner Some Yes Some Some No Junior hospital nurse Yes No No No No Senior hospital nurse Yes No Some No No Paramedic Some No Yes No No Home care nurse Some Some Yes No Yes Junior Radiologist Some No No No No Senior Radiologist Yes Some Some Some No Table 6-1 Generic Mobility Requirements For Classes Of Clinicians This communication usually has to be "seamless" in that connections are not lost when transitioning between networks or between connectivity paths/access points within the same network, and the end user should not be perturbed by a mobility event occurring either within a network (where the service level before and after the mobility event will be likely to be broadly similar) or between networks where the service capability and structure may have to be adapted to match the change in network characteristics and capabilities between the "before" and "after" mobility event network connections.

Nortel Confidential 88 of 226 One of the more extreme examples of this would be a transition from an 802.11 a or 802.11 g WLAN (with up to 54 Mb/s phy-level throughput and an ability to support data bursts per user at the service level in the region of 20 Mb/s, to a cellular network supporting a few tens or hundred of kilobits/sec per user at best. Unexpected transitions between networks of widely different capabilities have the potential to cause users significant concern, since their effects may appear to be similar to network failure events even if both networks are functioning correctly. For this reason mobility events occurring between disparate networks may need to provide some form of prior indication to the end user that a controlled change is about to occur.

6.3 Routine, Emergency Another method of segmenting clinical activities and their supporting services is to separate them into Routine and Emergency activities and applications. Routine events are those a clinician can usually anticipate, plan for and which the clinician will often carry out many times a day or many times per month. Routine events are often scheduled, whereas Emergency activities are often unanticipated, unplanned, unexpected and a cause of much activity until they are resolved.

6.3.1 Characteristics of Routine Events These are likely to be occurring in a widespread manner, regularly, and often or continuously in time. Their utilization is generally unremarkable and the operation of the communications and IT system must be unobtrusive, although highly supportive.
Routine events usually have an anticipated and generally predictable or semi-predictable outcome, punctuated by a very few cases of a different, divergent or difficult outcome, which may be the trigger for an emergency event. Routine events normally do not generate unplanned or unanticipated activity at the macroscopic scale, but generate different detail outcomes usually within an anticipated range on a case-by-case basis. Since routine events occur frequently, sometimes more or less continuously, lack of user friendliness or ease of use in a clinical communications and IT support capability will significantly decrease both the efficiency/effectiveness improvements achievable, and will result in extra end user clinician stress and less user acceptance. In terms of dependability infrequent short network outages, or reductions in service are not quite as critical as in the time-critical emergency case - but overall availability and dependability must still be extremely high.

6.3.2 Characteristics of Emergency events Emergency events may be moderately common, particularly in an Emergency Room or Intensive Care ward or may be relatively rare or very rare events, for instance in an out-patient setting or in a radiology lab setting. In the cases of a rare emergency the responding Clinicians and hospital staff may not be sure what to do, since it may have been a long time (and a very large number of routine activities) since the last time they Nortel Confidential 89 of 226 had to respond in a similar way. The occurrence of emergencies is usually not anticipated / expected (with the notable exception of the Emergency Room) and may have wide range of expected or unexpected outcomes. In this situation the communications and IT
support infrastructure must be utterly dependable and must be easy to use and user-friendly, since the clinicians have enough to deal with as a result of the clinical emergency without having to deal with cantankerous communications.

Responses to Emergency situations, both clinical and non-clinical must often be very rapid, very precise in form since the difference between actions leading to success and failure in containing or recovering versus loosing control of the situation may be very small. For this reason many hospitals, hospital groups or healthcare organizations use a codified response for many of the emergency situations, which has the dual advantages of the notification of the situation existing is very rapid ("call Code") and that the staff can be trained to specific situation responses which enables more effective teamwork when a code is called. The Code scheme is not universally the same across all hospitals and the one we will use in this document is the one adopted for Ohio Health. Their Code names and high level definitions are given in Table 6-2 Ohio Emergency Codes.

Ohio Emergency Codes COC}E NAME EVENT
Fire Code Adam InfantFChild Abduction Bomb/Bomb Threat Code Gray Severe Weather Code Orange Hazardous Material Spill/Reiease Medical Emergency -Adult Code Pink Medical Emergency - Pediatric Code Yellow Disaster Violent Patient/Combative ._,_.......
Code Silver Person with Weapon/
Hostage Situation Mlssing Adult Patient Table 6-2 Ohio Emergency Codes Since the situation around an emergency is necessarily one of urgency and stress on responders the Communications and IT Solutions for their use must be intuitive or allow very rapid familiarization. One way to achieve this is to ensure that the operation of the emergency support tools is very similar to the operation of the routine tools wherever this is possible. For instance, while the emergency team formation to treat a Code Blue victim is unique, the treatment of that victim by the formed team can be regarded as an Nortel Confidential 90 of 226 extremely high stress, urgent and important version of a Point of Care session, with similar interfaces and tools.

Emergency clinical events often trigger intensive activity including extremely time-critical activity. This may bring the entire hospital system to the brink of overload, especially for disaster response, where multiple such events are occurring simultaneously - ECAS system should be a dependable source of help, and not a hindrance in such extreme circumstances.

6.4 Clinical involvement Another way to characterize applications is as to their degree of clinical involvement.
Many activities and applications in a hospital are independent of clinical activity and could just as well be occurring in a factory, finance center or airport -these often have to do with the operation of the business side, or safety (e.g. hazard detection/avoidance) or protection and security, either of information, personnel or equipment. There are also applications that are linked to clinical practice but are not engaged into it, applications that are engaged into clinical practices and which may enhance those practices, and lastly there are applications of IT and Communications technology which may enable radical new clinical practices.

6.4.1 Independent of clinical practice These are applications which have no significant clinical involvement and which could be applied in a non-healthcare setting. Examples would include the emergency response to a fire or hazardous material release or the location of equipment for inventory purposes, which in other settings would not be medical equipment.

6.4.2 Linked to clinical practice These are applications which have not specific clinical involvement themselves but which provide useful or significant enabling inputs or information into clinical, clinically engaged or clinically enabling applications. Examples would be clinician location and tracking as an input into a clinical collaboration application, patient/clinician proximity discrimination and association as an input into PoC tracking 6.4.3 Clinically engaged Clinically engaged applications are those woven into or intimately supported clinical activities, but where the clinical activity could still go ahead in a modified less optimized way without the application. The injection of clinical IT into the Point of Care processes can either be Clinically Engaged or, if taken to extreme, Clinically Enabling.
Other Nortel Confidential 91 of 226 examples include selective pre-fetching of clinical information to the Point of care, based upon the clinician profile, the clinician-patient proximity to enable a more effective Point of care encounter.

6.4.4 Clinically enabling These are applications which allow or enable clinical concepts, processes or procedures which would be too risky, impractical or downright impossible without the Clinically Enabling IT. These applications, as they are discovered, can be the pivotal points for radical transformations. One example, which is beyond the scope of this document, but can be covered in a home healthcare phase, is the use of home patient health and activity monitoring to allow much earlier release from hospital while still under medical care.
Another example would be the introduction of closed loop patient drug administration in hospitals, which has been shown to be potentially able to reduce the rate of occurrence of ADE's down form 770,000 to just 15-20% of this. This would avoid around 600,000 medical emergency events and might save 5,000-6,000 lives annually.

6.5 Clinical Applications Many of these applications and aspects are provided at the user-specific interface level by software suites from major clinical software vendors such as Cerner, McKesson, Eclipsys, IDX, MiSys, GE (Radiology), Mercury MD, etc. These companies develop and market software suites that use existing standard IT practices and infrastructure and, as a result, are often limited by that infrastructure as to their intuitiveness, userO-friendliness, dependability, overall performance, etc. Some example software packages are those from Cerner, McKesson and Mercury MD, to pick three.

Cemer has a family of offerings for different parts of the healthcare environment. Its main offering for hospitals is Cerner Millennium 2007, available for distribution November 15, 2006. This release is the 15th major release of the unified Cerner Millennium healthcare information technology architecture, and offers Solution Area Segments of: -Access Management Biosurveillance Cardiovascular Clinical Imaging Community Health Consumer Health CPOE Critical Care Document Imaging Acute Care Electronic Medical Record Emergency Department Health Information Management Homecare Knowledge Solutions Laboratory Healthcare Devices Oncology Outcomes Management Patient Accounting Patient Care Perioperative Pharmacy Physician Practice Nortel Confidential 92 of 226 Point of Care Radiology Revenue Cycle Supply Chain Women's Health Workforce Management Each of these breaks down further into a series of software applications and modules, often shared across solutions. For CPOE these are: -PowerOrders - physician-centric ordering PowerChart - electronic medical record and data repository Discern Expert - decision-support engine Executable Knowledge - embedded knowledge from industry-leading sources Care Docunzentation, Medication Adnzinistration Record - automated clinical documentation PowerChart Office - ordering and electronic prescription-writing in the ambulatory setting Advanced Medication Management - complex order entry, such as weight-based dosing and linked orders PowerNoteTM- structured clinical documentation Other areas may be addressed by a single comprehensive package. For instance Cerner offers such a package for Emergency Rooms or emergency departments. Cerner's ED
information system, FirstNet supports a wide range of functions, including:
- Integration of pre-existing documentation into the patient's electronic ED
record (physician office, prior hospital, pre-arrival ambulance records, etc.) - Registration - Triage and tracking - Orders, including laboratory, radiology and medication orders and results - Nursing documentation that works in conjunction with ED-specific processes - Dynamic, complaint-specific physician documentation designed for the ED
- Professional and facility coding and billing - Discharge planning including education materials, follow-up instructions and prescriptions - Management reporting - Decision support, alerts and notifications - Risk management, including alerts and interaction checking For more details visit http://www.cerner.com/public/

Nortel Confidential 93 of 226 McKesson offers hospitals a family of products to manage hospital costs, increase patient safety, maximize reimbursement, strengthen physician relationships, and facilitate appropriate patient care. These solutions are: -Manage Operating Costs - Pathways Materials Management - Horizon Surgical Manager - Horizon Business Insight Increase Patient Safety - Horizon Admin-Rx - CarePoint-RN
- Horizon Meds Manager - Horizon Lab Maximize Reimbursement - EC2000 Claims Administrator - Pathways Compliance Advisor - Pathways Contract Management Strengthen Physician Relationships - Horizon WP Physician Portal - Horizon Medical Imaging - Horizon Expert Orders - Horizon Ambulatory Care Facilitate Appropriate Care - InterQual Decision Support For more details visit http://ww ,.mckesson.com/enus/McKesson.com/

As can be seen from this impressive list, which just touches the surface of these companies' capabilities, they have a massive expertise and depth-of-knowledge in this field as well as extremely well developed channels to market. Hence, with these vendors and other major vendors already in-play in this space it would not be appropriate for Nortel to attempt to directly enter the space of clinical applications themselves.

But all of these vendors have a common weakness - their solutions, which have to give the absolute highest of performance, are all to some extent dependent upon the network infrastructure on which their applications reside, its properties and capabilities.

By providing a better, more capable, more dependable, more adaptive, more secure solution infrastructure along with advanced clinical communications solutions and applications, where our skills can be brought to bear, we can provide a much more capable environment for the actual clinical applications to interact with, including new capabilities that can reflect as new clinical capabilities. This is a possible path to explore to see if partnership or collaboration opportunities can exist.

Nortel Confidential 94 of 226 7 Application Of ECAS To Healthcare This section will look at a number of areas where ECAS can enhance Communications and IT impact on healthcare clinical processes, both routine and emergency.
While the list of applications presented is fairly long it is not in any way claimed to be complete or exhaustive, for instance focusing mainly on applications and scenarios useful in the general hospital areas rather than in radiology (which has been covered elsewhere) or in the Operating Room (OR). But this will allow for a preliminary definition of an infrastructure suitable for advanced Healthcare Informatics and Communication within a hospital. Furthermore a basic structure for the interdependencies of these services and functionalities will be presented, although not yet at the level of a formal services UML
model.

The services that will be presented will range across routine and emergency, across clinically independent to clinically critical. The list of example services is: -a) Some major routine application areas a. Clinician Coordinates Location And Context b. Patient Tracking And/Or Monitoring c. Equipment Tracking, Location And Condition d. Equipment/Clinician Or Equipment/Patient Association e. Clinician Point Of Care Communications f. Clinical Collaboration g. Drug Safety, Security And Environment h. Various Applications In Support Areas i. Routine equipment and terminal calibration, maintenance and verification b) Some major emergency application areas -a. Emergency (E)"Code" - Various Emergency Codes (as per Table 6-2) i. Code Blue/Pink - Emergency Cardiac/Respiratory Event -Adult/Pediatric ii. Code Adam - Missing Infant Or Child iii. Code Brown - Wandering Patient Protection iv. Code Yellow - Disaster Response v. Code Red - Fire vi. Code Orange - Hazardous Material b. Drug Theft Or Tampering Detection c. Equipment Theft Or Movement Outside Of Authorized Zone - Detection These services are highly interdependent on each other and both form a kind of hierarchy and exhibit some strong associations between some routine and some emergency events.
The big picture we will be exploring is shown at a high level in Figure 7-1 and in more detail in Figure 7-2, Figure 7-3 and Figure 7-4 in a later section.

Nortel Confidential 95 of 226 ----- --=-- --------- Hospital Clinical , .
HIS HCIS
Facility Clinician Patient Patient Facility, Staff and data data data Clinical data Patient databases and infrastructure - -, .-. _ __ - _ ' - ----- - -- =- ~
Context Conventional information Clinical services - Hospital IT &
gathering & clinical IT
e.g. Clinical Collaboration, POC, Code Blue processing solution Non-clinicai services -e.g. Equipment tracking and theft pro#ection, drug physical safety . _ --- ___ ----~
Location-proximity based association and sensor association e.g. ciinicianle uipmenUpatient association Environmental Awareness and Basic Environmental Awareness Context e.g. Location, sensors Figure 7-1 Scenario Interdependencies- high level Figure 7-1 shows a basic hierarchy of services and their relationship to the core Hospital Information System (HIS) and, within this, the Hospital Clinical Information System (HCIS). The four main areas in this figure are: -a) The core Hospital clinical, facility, staff and patient databases and infrastructure that makes up the HIS.

b) The conventional hospital IT and clinical IT solution elements c) The additional functions providing environmental awareness and environmental context information d) Overall context gathering and processing across the facility, leading to context/situation-based decisions within ECAS. These are then applied to modify the nature, scope and occurrence of communications.

The core Hospital clinical, facility, staff and patient databases and infrastructure that makes up the HIS can be considered to consist of two main components, the Hospital Information System, which handles the non -clinically sensitive data and information of the hospital and the closely guarded, very secure Hospital Clinical Information System, which contains the clinical data for current, prospective and past patients and which is subject to stringent Health Insurance Portability and Accountability Act (HIPAA) requirements in the US and Personal Information Protection and Electronic Documents Act (PIPEDA) privacy requirements in Canada as well as similar requirements in other countries. The HIS consists of general facility data, such as financial data, building Nortel Confidential 96 of 226 maintenance schedules, general purpose data networking and so on, as well as a database of which clinicians are accredited, what their rights and privileges are, their work schedule and preferences including their IT preferences, etc. Neither of these contains any clinical information about the patient base although they may contain non-clinical data about the patient base. The HCIS contains all of the sensitive clinical data and includes two resource groups, being information on the patient and clinical information on the patient. Both are required to be kept private. Information on the patient may include ordered tests, schedules, patient-clinician associations, etc. while the patient clinical data consists of EHR, EMR clinical data, clinical data, images, etc.
for patients, ordered treatments, diagnoses and other clinical data that can identify the patient condition. Often the boundary between the Patient Data classification and the Patient Clinical Data classification can become blurred so both are ring-fenced inside the HCIS.
Within the conventional Hospital IT ands Clinical IT solution is a relatively conventional communications and IT infrastructure, although hopefully engineered to Clinical Grade standards. This infrastructure throughout the hospital supports both Clinical Services, such as clinical collaboration, Point of care information sessions, response to Code Blue and other emergency (and routine) clinical actions, etc. It also supports a suite of non-clinical services such as may occur in any large business facility, as well as more advanced non-clinical services and clinical services arising from the application of ECAS.
The Environmental Awareness and Context area of Figure 7-1 consists of basic environmental awareness, the detection of key environmental primitive information, such as the fact that sensors # 658-671 are reading +400 C whereas all the others are reading between +20 and +23 C, or that an item with a identity primitive of Object 893 can now be found at coordinates 453, 235,12. This information is of very limited use unless put into context by both performing location/proximity based association or sensor field analysis as well as deriving context based upon policy and information about what should be the results from the environmental primitives. For instance if sensors 658-671 were in a storage room this might indicate a serious problem like a fire in that storage room but if they are on the chimney flue of the furnace they may simply indicate that the temperature outside the hospital is very low so the furnace is working overtime to heat the building.
Information from all three areas is brought together in the fourth area, the context (or situation) gathering, processing and decision-making stage. This takes the processed information from the Environmental Awareness and Context area, combines it with policies and permissions from the core Hospital Clinical, Facility, Staff and Patient databases and infrastructure, both in response to user and network requests and activities within the conventional Hospital IT and Clinical IT solution and in order to modify the action of the conventional Hospital IT and Clinical IT solution. This may be as simple as denying access to a user based on the assessment that this is not a legitimately authenticated user or may be the rearrangement of communications services on behalf of a clinician, based upon where that clinician is, who they are with or what they are doing.
Nortel Confidential 97 of 226 Before we can explore this further we need a better understanding of the nature of the clinical communications and support services themselves, which is addressed in the next two sub-sections, as well as in the appendices-Sections 14-16 in great depth.

7.1 Some major routine application areas - end user perspective This section looks at a high-level clinical or pseudo-clinical definition of the routine services or applications - how an end-user would see them - as well as some of the basic support services that enable the more advanced clinical services to exist.

7.1.1 Clinician Coordinates Location And Context This service can identify whether the clinician is in the facility and where the clinician is located in the facility for all appropriate parts of the facility but not elsewhere. The location service is primarily used as an input to other services as opposed as a method of tracking the clinicians as an end objective, which would have major privacy issues. The data generated by this application to other applications may simply clinician presence, identity primitives and coordinates or may be passed through a context analyzer allowing a hospital map to be superimposed on the results to provide the clinician location in the form "Dr. Jones is in OR #6" or "Nurse Smith is in Ward 10"

7.1.2 Patient Tracking And/Or Monitoring The patient tracking and/or monitoring application will determine, at any given point in time, where a patient is within the facility. Like the clinician location application, this application is a basic application, mainly to provide input to other applications.

7.1.3 Equipment Tracking, Location And Condition This application is the third basic location ands tracking application and provides physical location information for any appropriately equipped or tagged equipment. It is used mainly as an input to other applications allowing inventory control, locating equipment at times of clinical need and as a theft or misappropriation deterrent. Like the other two basic applications it can either provide just basic location coordinates and identity primitives for the equipment or can apply a location context filter to determine which room the equipment is in and even if the equipment is in a place it is not supposed to be.

Nortel Conftdential 98 of 226 7.1.4 Equipment/Clinician Or Equipment/Patient Association Many clinical services make use of the actual position of the clinician, patient or equipment within the facility but many more do not need absolute location but rather make use of the relative locations of two people, equipments or combination of people and equipment. These services need to know who and what is proximate (i.e.
close to each other - in physical proximity) and this can be performed by comparing absolute coordinates of people and objects as measured by the systems for examples 7.1.1 to 7.1.3 above, providing they can provide adequate precision and accuracy, or can be provided by proximity detectors on people or equipments. Either way, once a proximate relationship is established then the proximate people and equipments can be said to be associated. Whether or not association is established, the criteria for maintaining it, the criteria for suspending or terminating association will form part of an association policy or algorithm. This association may then be used by higher level clinical services.

7.1.5 Clinician Point Of Care Communications Clinician Point of Care Communications occur when a clinician fetches, uses, generates or disseminates information while in the process of clinically interacting with the patient's condition. Clinical Point of Care communications can occur at the bedside or other location where the patient is present but, in one definition, it can also take place remotely from the patient, for instance when two clinicians consult or collaborate to identify or resolve an issue relating to the patient (this second instance is also sometimes referred to as the Point of decision). Point of Care Communications do not have to be electronic and traditionally have not been but the Point of Care is a natural point for the clinical application of IT and this is occurring at a fast pace. Here we are only interested in the electronic form, within an HCIS framework. As a result of this HCIS
framework clinicians can access full patient records, lab tests, images, etc. can make and capture decisions use decision validation tools and place clinical work orders and prescriptions without leaving the Point of Care and without having to transcribe notes later. This is expected to result in substantial improvements in clinical effectiveness, and allow the practical application of decision support tools to catch potential medical errors and injuries before they happen.

7.1.6 Clinical Collaboration This occurs whenever two or more clinicians share and discuss a clinical situation or jointly communicate to alter that outcome. Clinical collaboration is an initial part of many Point of Care sessions but not all clinical collaborations are associated with Point of Care sessions.

7.1.7 Drug Safety, Security And Environment Nortel Confidential 99 of 226 This application has several aspects. These include ensuring that the whereabouts of drug supplies are known (a security-based location issue), that the drugs have not been exposed to a detrimental environment, which,, dependent upon the drug type, can include heat, cold, light, IR radiation, gases or other chemicals, humidity, etc. This is a sensor based tracked item history issue. But there is a third aspect - if the drugs can be tracked for security purposes they can also be tracked for drug administration purposes with an extension of the same applications, allowing closed loop drug administration which has been shown to radically reduce the number of ADE's that should occur in hospitals - by up to 80 or even 85%. This needs a significantly different solution optimization to the security driven drug tracking, mainly within the pharmacy and central stores.

7.1.8 Various Applications In Support Areas Various applications are expected to become apparent in Radiology and other imaging support departments, in test labs, clinics and outpatient treatment areas, etc.

7.1.9 Routine equipment and terminal calibration, maintenance and verification A hospital already has a large amount of sophisticated medical equipment and will add a large number of portable hand-held terminals and fixed wired terminals as it moves into a Clinical IT intensive solution. All of this equipment must be tracked, but it must also be periodically inventoried and even more frequently checked as to its operating condition and status. This may include whether a medical instrument rechargeable battery pack is fully charged, when the instrument was last calibrated, whether it was cleaned after its last use, etc. Keeping equipment clean, calibrated and operational is a major challenge for hospitals since without automated location and condition checking each instrument has to be physically visited and tested in situ or back in a calibration lab -just finding the equipment to start this process can be difficult.

7.2 Some Major Emergency Application Areas - end user perspective This section looks at a high-level clinical or pseudo-clinical definition of the emergency services or applications - how a clinician would see them - as well as some of the non-clinical emergency services that have to exist.

7.2.1 Emergency (E)"Code" - Various Emergency Codes As indicated earlier a hospital has to have a well honed action plan to deal with emergencies as and when they arise. Some emergencies, especially clinical emergencies are part of day-to-day life in a hospital while some other ones hopefully are never Nortel Confidential 100 of 226 encountered in a hospital and are sometimes potential catastrophes in the making when they do occur - emergencies such as "Fire! !!". The various emergency situations and required staff responses are mapped into a set of identified emergency scenarios and action plans. These scenarios and action plans are given "Code" names, which can be called, broadcast or otherwise disseminated. There seems not to be a totally universal definition of which emergency scenario and response action plan receives which Code name, although some are common across the industry - notably Code Blue for adult cardiac/respiratory failure potentially leading to death without intervention.
For this document we are using the Code definitions and names as used in Ohio, since we have relatively good information on this. The Ohio Code titles and meanings were given in Table 6-2.

7.2.1.1 Code Blue/Pink - Emergency Cardiac/Respiratory Event -Adult/Pediatric "Code Blue" is called in the event of a cardiac/respiratory failure event requiring clinical intervention to save a life in the event that this does not occur while an appropriate response team is present (e.g. in an OR the team would be present, in a bed ward the appropriate team would not probably be present). At the calling of the Code Blue the members of a designated response team leave what they were doing and converge on the Code Blue casualty site, along with the necessary resuscitation equipment. At that point the Code Blue exits the urgent team formation stage and becomes a clinical treatment/
resuscitation activity complete with a rather urgent, high stakes Point of Care communications component and a clinical collaboration component.

Code Pink is the same sequence of events but in response to the need to resuscitate a minor, infant or baby.

7.2.1.2 Code Adam - Missing Infant Or Child Code Adam is called should a child or infant be found to be missing from where they arte supposed to be and the circumstances suggest an abduction or other suspicious situation.
A Code Adam should not be called for a late return of a young teenager from a trip to radiology for instance but probably should be called if a newborn disappears from its crib in the nursery. A Code Adam causes a virtual lock down on the hospital in an attempt to prevent the egress of the victim, combined with a search of the premises and, at the appropriate moment, notification of the authorities. Code Adam's are highly disruptive to a hospital routine so spurious ones are to be avoided.

7.2.1.3 Code Brown - Wandering Patient Protection Code Brown has some similarities to Code Adam. In this case the patient is elderly, or not in full control of his or her faculties and may be prone to simply wandering off. A
hospital can be a dangerous place for an infirm, elderly or frail person, particularly if they Nortel Confidential 101 of 226 go where they are not supposed to, so it is necessary to locate a wandering patient with a high degree of urgency, including a partial lock down to prevent them exiting the building. The main difference between a Code Adam and a Code Brown is that, in a Code Adam there is an expectation that a crime may have been committed but in a code Brown there is a concern for the patient's well being as a result of their own actions.

7.2.1.4 Code Yellow - Disaster Response Code Yellow puts the hospital on an emergency response setting in the event of a major external disaster, such that normal operations of the hospital might be overwhelmed by the volume of incoming patients. It establishes and activates a number of emergency protocols to allow the hospital to better respond to the emergency situation at the expense of shelving some routine activities. Example triggers for Code Yellow might be a major terrorist attack, a major plane crash, a multi-vehicle freeway pile up, or a school shooting rampage.

7.2.1.5 Code Red - Fire Code red triggers a fire response protocol and fire defence, containment teams and actions, as well as notifying local Fire Departments. In a large hospital people in harms way would have to be evacuated but often evacuating ill patients not in danger may do more harm than good. So the Code Red does not necessarily trigger the complete evacuation of the facility. However a fire and the resulting Code Red is highly disruptive and in addition errors in evacuation (such as an incompletely defined evacuation area or people left behind within a defined evacuation area) can cause serious problems up to loss of life.

7.2.1.6 Code Orange - Hazardous Material Code Orange has most of the same attributes as Code Red, but is triggered by a serious Hazardous Material Release (HMR). It activates specially trained Hazardous Material Release Response teams, rather than fire fighting teams, although many fire-fighting teams have appropriate experience in dealing with hazardous materials and so may be involved.

7.2.2 Drug Theft Or Tampering Detection This is the emergency equivalent of Drug Safety, Security And Environment listed above, and is concerned with detecting drug tampering, or drug theft. It odes not have an Ohio Code designation.

Nortel Confidential 102 of 226 7.2.3 Equipment Theft Or Movement Outside Of Authorized Zone -Detection This application is concerned with ensuring that inappropriate movement of equipment is detected and action taken before equipment is stolen from the facility or is moved in an inappropriate way to another part of the facility. To achieve this outcome the equipment location must be tracked and any person who is proximate to it and appears to be tracking it must be identified and the situation assessed as a result of this, then action taken based upon this situation. As an example a tablet PC traveling to the front door without an observable clinical in continuous proximity is likely to be being stolen so security needs to be dispatched whereas that same device traveling with its authorized physician owner is probably Dr Jones taking home his tablet PC so the appropriate response is to log him/it out of the building. Similarly if the Crash Cart that belongs in OR # 1 is seen heading across the hospital, in the company of a clinician who has no access privileges in OR # 1, action needs to be taken that is different to if the same event is happening and the associated person is an authorized calibration/repair technician, there is an open trouble ticket ion the instrument and the path being taken is towards the maintenance department.
7.3 Clinical Communications And Support Services Relationships Figure 7-2 shows the relationships between the various routine and emergency clinical communications and support services described in the previous two sub-sections, from a layered services and information flow perspective. At the head of the Figure is the HCIS
and HIS, most of which has to exist in the pre-ECAS world. Under this are the ECAS
clinical services with some grouped examples shown. These communicate with the HIS, the HCIS and the environmental layers below them. The non-clinical layer, also with some examples shown communicates with the HIS and the environmental layers below them. The Base environmental layers receive mapping, zoning and facility data from the HIS and provide environmental input into the clinical and non-clinical services above them.

Nortel Confidential 103 of 226 ~. ~ - .,. -i,...__ ._ ~.,~õ~ - - - .w .,. __ ... - - ,~, ~, ~- _ _ ~,. - ---------------i HIS - HCIS_ Facility data Clinician & staff data Patient data Patient Clinical data li m FD' D=
, Digitized facility map Clinician ID Patient ID Patient EMRlEHR H.
E Map of Dep'ts and Zones Clinician ID I Tag ID Patient ID -~ Tag ID Patient EPR ~
Allocation of e ui ment ~ De ts Em lo ee ID Patient classification Drug treatment, prescriptions; ii o y T m q p P' P Y. pt y Drug environment database Employee ID 4 Tag ID Patient zone limits -Orders ~ y su Authorized drug handlers Clinician shift schedule nditionaluuncondmonal Decision validationresuRs i a__ Emergency response policy Employeeshift schedule Patient conditional Referrals and results N
Equipment inventory with S/N Clinician patient list constraints Allergies (p Equipment SIN 4 Tag ID Clinician tenoinal type Patient status Results - tests and imaging t/t y=
Equipment movement policies I Emergency response team list , I Patient Scheduling Radiology I~ Qe y 0 Drug cart routes & store locations! Security staff list/schedule Dietary First responder input Hazardous material map HMR, fire-treined staff Etc., Etc. Consultation notes Response & ventilation map Etc., Etc.
_....... ___._;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -I- - - - - - - - - - - - - - - - - - - -.- -.--.-..-.-.'..-.-.- ~
. I . i R6 = Clinical El = Code Blue - emergency Clinical õ~ . . . eollaboration cardiaclresplratory event -adult ....................... n services I ~; .~x = R7 - DrugnvironmesnN R6 - Clinician Point ot E6 - Code Yellow - I
jexamplesl E- = securR anCare communieations ........ Dl..saster Response I -~- - - e ~ - -... ..
- ~. - - - - -: õ .. -- ~'- ~ - - -= -- EB - Drug theft . - - - a - ~,~'~, - - - - -...........= ............ : ortampenng - u.. .
detection y is .. ........................:
, =
Non-I. : M E2 - issmg Code Adam - infant or child = ...................
... = . E7 - Code Orange - ------I~ E9 - Equipme Hazardous Material 1 cllDlcal . . = _ E3 - Code Brown - theft or movent ment .
= S@rVIC@S
Wandering patient .
~6 - Code Red - Fre _ 1 =---------.
protection' outside of auther_ed zone .........................:
`_______--------.::...--- --- -----r-------- = --- --- -- --, ~ Location-oroximitv p4-Equipment ,Ilnician,equipment' .. ' i based association and atient or clinic npatient assoclation sensor association - - - - - - - - - - - - - - - - -; ~'----~---... ------- .z~---- .---T
I R1 - Clinician R2 - Patlent R3 - Equlpment 8asic sensor T Baslc ~oordinates location tracking,and/or tracking, location ~ layerand I
Environmental = and context monitonng 'and condition structures I Awareness - - - - - - - - - - - - - - - - - - - - - - - - - -Figure 7-2 Scenario Interdependencies- For Groups of Service Types This high level view can be broken down some more. Figure 7-3 shows a possible structure for how the majority of the clinical IT support services and applications listed at the beginning of Section 5 can be mapped into a structure and the interfaces between them.

It is important to note that this is just one view of this, which is not claimed to be complete, and is subject to substantial evolution as we learn inore.
Nevertheless this structure will teach us a lot of how these capabilities and services have to be structured internally, how they interrelate and what information has to flow between them as well as the functionality of each service or application. It also shows examples of various types of services, where they fit and how they can relate, including how some routine and emergency services can be relatively common.

Nortel Confidential 104 of 226 ......... ..__ HIS HCIS Hospital Clinical.
Clinician Patient P---Facility Facilitv, Staff and data data data Patient databases ' and infrastructure ...........................................
.........................................
= R6 - Clinical E- Code Blue/pink - emergency coaoraon rdiacirespiratory event - adult/pediatric Clinical services ; R5 - Clinician Point of Care E5 - Code Yellow - ryices R7 - Drug safety, ; : communications Disaster Response E
security and ................... .... . ...................................
~., .............................
environment ,.. .................... 4 E8 - Dru theft E2 - Code Adam - """""""""' E7 - Code Oran9e-g Missin infant or E9 - Equipment theft or tam erin g : Hazardous Material p g child or movement outside y 2 detection of authorized zone - c 'I
E6 - Code E3 - Code Brown - detection Red - Z
Fire Wandering patient ...... ..............: y :
protec6on`
........... ....,= . ... ,.

R4 - Equip't/ clinician, clinician/ b. . .
sensor association R1 - Clinician R2 - Patient R3 - Equipment Basic sensor Basic coordinates location tracking and/or tracking, location layer and Environmental and L:ext monitoring and condition structures Awareness Figure 7-3 Scenario Interdependencies - For a wide range of example clinical, non-clinical and emergency services At the top of the diagram the hospital clinical, facility, staff and patient databases and infrastructure is shown unchanged (it will be expanded on later). Under that is a layer of clinical services of which examples are given as E 1 Code Blue/Pink-emergency cardiac/respiratory event-adult/pediatric, which is associated with R6 -clinical collaboration and R5 - Clinician Point of Care communications. All of these are associated with E5 - Code Yellow - disaster response. These are associated because they share many of the same requirements, functions, attributes and information flow and connectivity requirements. Furthermore they should all present their clinical information to the end user in the same manner and have similar user profiles, although the circumstances for their use may be quite different.

Underneath the clinical services layer is shown the non-clinical services layer. These may be services which, although not clinical services in themselves, provide vital direct support to clinical services or they may be services separate from clinical services. All of the examples shown are, in fact, emergency services although this will not always be true and some of the emergency services shown in the figure also have non-emergency equivalent services - for instance the service E9 - equipment theft or movement outside of authorized zone has a routine counterpart, not shown in the figure, for routine equipment tracking and accessing for maintenance/calibration purposes or for locating (inventory control) before a routine clinical procedure or even for an annual audit.

Nortel Confidential 105 of 226 The services shown as E7 - Code Orange - Hazardous Material Release and E6 -Code Red - Fire have substantial commonalities, both being involved in evacuating part or all of the building, understanding the extent and spread of the fire and smoke or products from the hazardous material and identifying people and equipment at risk in the vicinity as well as helping provide data to coordinate the containment and elimination of the threat.

For the same reason - massive commonality of form and function - E2 - Code Adam -Missing Infant or Child, and E3 - Code Brown - Wandering/Lost Patient can be grouped.
E8 - Drug theft or tampering detection and R7 - Drug safety, security and environment can also be associated. This pair are shown placed slightly higher in the figure than the others since R7 would have a clinical component to it if the drug safety and tracking the whereabouts of the drugs is extended through to patient administration in which case an extension of this application can provide drug dosage verification, although this is not shown in this figure.

Below the non-clinical services are shown some of the basic Environmental Awareness and Association/Proximity/ Sensor Association functions and support services.
The sensor association and data extraction function is not explicitly shown in the figure but would occupy the area denoted by a dotted box in the bottom right quadrant.
The lines between the individual applications or dotted groupings of applications represent the most significant identified linkages between them. These linkages, in terms of input and output information will be detailed in the following sections as part of the discussions around the functionality of each of the applications and services.

Some of these services, a representative selection, will be also further drilled down to show more detail of how they would operate and what demands they would place upon the ECAS solution as well as on any Clinical Grade IT and Communications infrastructure.

Figure 7-4 complements Figure 7-3 in that it shrinks the area shown in detail in Figure 7-3 and expands the top area of Figure 7-3 to show some of the necessary support functions and structure within the HIS and HCIS.

Nortel Confidential 106 of 226 ---------------- ---------HIS HCIS
....... ... .... .. o e Facility data Clinician & staff data Patlent data Patient Clinical data _ . , Patient PatleM ' Dlgrtlzed faclirty Eqwpment Cliniclan Clfnlclan ID Patient ID W
map Inventory with SM CD 4 Tag ID Patient ID ,Tag ID EMR/EHR EPR a d Map of Dep'ts ~ Equipment SIN Chmclan Chmclan `Drug Results m n and Zones '~ ~ Tag ID aUent hst~ tennmal ryP' e !Patient Patient zone reatment tests and classfi ~ its catlonj Ilm prescnptw 'Ima m y Iloeation of EquipmeM Employee . Employee uncondlhonal n d quPipment ~ movement i ID ID ~ Tag ID ' -- -i'Orders Radiology ~De ts pollcles . Patlent zone fPatieM
rEmergency Employee IImAS = condltlonal m m ~Dru envlronmenYl Drug caR routes res onse shift .condlhonal Deaslon First o g ~I constramts a _ database & sto re locatwns team hsts schedule . vahdatwn responder - ~ ~-~-- - - Patient PaUent results in ut ~
Authonzed Hazardous Security Clinician Scheduling status drug handlers ~atnal map employee shift and Consultatlon ~
notes ~ ~ IisUschedule schedule Dleta ~
. .. ........
~
results rEmergency Response8 ETC ~ e s ry -~ ETC Aller9ies ETC. ' ~ _ resP. . onse.P...=...... ollcy ...ventllation map ! HMR flre .,... . _. . .. . I
1 tralned staff ~ _J
.................... .....~
........
;...... 1........ -.... ....

............... ,:.. ...
Re-Cbncal I E eet erpc ':;
eollabaatlo ~d e.pi ry -an I padeaic Glinlcal .................. . R6 LlnleunPo t iGre EC Code eH~
R] Dru9saleN. : cwnmuMCabon A p unN nd .............. ;.... . .....
E Gode d~a:n I E6 Or qe I
} ~ O 9m~ NewL b:ett I ..EP E9 P::re zM% Hazard W al ~.~
(j p '"e , w " mo ube a~ . f uM ed zor:e E6 C ed F ======= E] Cd Br tm f~e I
----------~ .....
LL
I R~ Equ~p4 IlmciaN miN
weem .y v fass iar n naaeaase ana ...,...~.,...5...
R1o Cllrtlclan R] PaEmt R~~oE nt R iC l1 Bas c qnlp~ yEnrtronm.ntal rdmMes bcaHon tr kirg anN trackin8. bcabon aye J
,ne opmex, m.be na ~nm:n [,w~, m Awa Figure 7-4 Scenario Interdependencies - For a wide range of clinical, non-clinical and emergency services Whilst Figure 7-3 and Figure 7-4 show very complex interdependencies these are a combination of a pre-existing set of functionality and complexity required for the basic pre-ECAS HIS, HCIS and clinical/non-clinical applications combined with the overlay of ECAS functions. Furthermore the ECAS overlay functions need not all be implemented simultaneously but rather can be introduced in steps as and when needed and as and when justified. This is discussed in more depth in Section 7.4 and in Section 8.5 for a specific roll-out.

7.4 Basic Functionality and Performance Requirements For Seiected Application Areas The various clinical, non-clinical, environmental-associative and environmental services shown in Figures 7-3 and 7-4 have been "drilled down" to a significant depth.
Section 14 - Appendix contains the details of that work for Routine Applications. Section Appendix contains the details for non-routine (Emergency) applications. Some of the applications were subject to a further deeper drill down - this is given in Section 16 -Appendix. The summary information for these appendices is given here.

Nortel Confidential 107 of 226 7.4.1 Results Overview- Requirements From First Level Of Drill Down The results from the first level of drill down, as detailed in Section 14-Appendix and Section 15-Appendix are given in Error! Reference source not found. for six clinical and non-clinical client applications using ECAS data. These applications cover both examples of the emergency and routine operation of the hospital, since, if we are seeking an ECAS
infrastructure that can support multiple applications across clinical, non-clinical, routine and emergency situations we need to understand the worst case or most extreme requirements.

Client App R4 Equip't/ E9 Equip't R5 Point of El Code E6/7 Code R7/E8 Drug clinician/ wander / Care comms Blue Red / safety and theft Parameter patient track theft Orange detect Number, type 2,000+, all 500+ 100+ peak 10-20 (staff Up to 500? 50 (drug carts), of equipments types terminals, Usually a lot plus pharmacy, crash cart, less ward drug closets etc.) Location 1-2 meters +/- 1-2 m +/- 1-2 m -5 m-) 1-2 m 2-5 meters for 1-2 meters precision (which room) (absolute), (absolute), (absolute), 20- nearby, non-(absolute) , 20-30 for absolute, +/- 20-30 cm +/- 20-30 cm 30 cm involved cm (associative +1- 20-30 cm (proximity) (proximity) (proximity) equip't, 20-30 proximity for drug (proximity) cm for involved admin) equip't Location Sub - second Sub-second Sub-second Seconds 4 Sub-second to Few seconds latency (300 ms?) (300 ms?) (300 ms?) Sub-second few seconds (absolute), sub-(300 ms?) second (proximity) Dependability 4 9's? 2-3 9's 3-4 9's 4 9's 3 9's? 3 9's?

# of 7-10,000 Wander -50- 3-5,000 Low (140/yr V Low Admin 1,000, theft events/day 100, theft 1-5 blue + pink) - low # overlapping 50+ A few 20+? Not common Very rare Common - 2-5 events simultaneous Precision of High - Wrong Medium - High - Wrong High - Wrong Med - more High -correct identity dinician/wrong theft detection clinician/wrong clinician/wrong important to drug admin, equipment = more important equipment = equipment = assess overall medium for theft significant risk being than what stolen ia si gnificant risk significant risk situation Battery life - Equip't maint Equip't maint Equip't maint Equip't maint Equip't maint Equip't maint tags cycles - cydes - cycles - cycles - cydes - cycles -many months many months many months many months many months many months Table 7-1 R3-Equipment tracking, location, condition requirements from selected clinical, non-clinical applications Error! Reference source not found. shows the requirements on the behaviour of the location/proximity ECAS components as a result of analysis of these 6 applications. The more stringent requirements are boxed in yellow to provide highlights. From this data an analysis of location requirements and a listing of candidate technologies and location solutions can be started. This is touched on in a later section of this document.

7.4.2 Detailed Requirements from Drill Down Nortel Confidential 108 of 226 Three service scenarios were taken to a new much deeper level of analysis.
Details of the deeper analysis are contained in Section 16- Appendix. These were Equipment tracking, location and monitoring for condition, Point of Care communications, walking through a clinician-patient encounter, and the automated formation of a Code Blue team using ECAS capabilities. In addition a fourth scenario was analyzed in depth but is not included in the appendix. This was Code Adam, called when an infant goes missing. The first view of quantitative requirements for these three detail service scenarios plus code Adam are given in Table 7-2 Quantitative Requirements Comparison.

Eauipment trackinu, Clinician Point of Care Code Blue (E7) - team Code Adam (E2) location and condition (R2) Communications (R51 forming phase Geography Campus in-building, one or a Campus Campus in-building, one Campus few buildings or a few buildings + 250 yards outdoors Scale 100's - 10,000's, 100's to 1000's, 100's or patients, 100's of patients, 1000's per floor, 100's per floor, Combination of R2 and combination of 100's per AP 10's per AP R5 R2 and R5 Location precision Room, 3m Proximity or 20 cni Room, 3m Proximity or Room Room, outdoor for advanced application 20 cm for advanced app's coverage Other sensors On medical equipment No No (biohazards??) No (heat??) Volume of data Kb/s Mbls Kb/s Kb/s Message Latency Second Sub-second for theft Seconds (user Sub-seconds Seconds applications satisfaction driven) App Availability" Medium - 0.99 to high 0.999 High - 0.999 Very high - 0.9999 High - 0.999 Frequency Routine-hundreds a day Routine - continual 200 per year for 400 Rare-less than 1 usage bed tertiary care per year hospital Criticality Moderate (for efficiency) Moderate (for efficiency) Mission-critical High Mobile devices Tag Phone with graphic Phone with graphic Phone with display, Tables, PDA's display, Tables, PDA's graphic display for EHR
Privacy Minimal, For patient data in High Minimal- during incident Minimal-during monitoring apps incident Security (of Medium High Medium Low (due to application access) rarity) Auditing, logging Yes Yes - Efficiency, Yes-detailed (?j , Yes (if required) malpractice Hospital may not want Mobile Device 6 months minimum (Tags) I day (shift plus personal 1 shift I
shift Battery timewhen on call) 6months min (Tags) 6 months min (tags) 6 mo min (tags) Data Location - periodic pings Voice Voice / Audio Voice / Audio Characteristics Condition - low data rate Text, Image Text Text messages Video - collaborative, Location Location Operational data - graphic or diagnostic web pages, low res video Web pages, e.g. EHR
such as EKG Location Web pages Data Rate Kb/s Mbls Kb/s Kb/s Privacy Minimal, For patient data in High Minimal- during incident Minimal-dunng monitoring apps incident Initial view - stringent requirement to meet- may need trade-offs Most stringent requirement Table 7-2 Quantitative Requirements Comparison Nortel Confidential 109 of 226 7.5 Modularity and Complexity The solutions presented here look very complex and indeed they are so. But part of that complexity is innate and is already in place in the pre-ECAS hospital world.
For instance in any modern hospital the HIS and HCIS complexity has to be largely in place and, while there are no ECAS components, there has to be solutions for clinician collaboration, Point of Care communication, various Code call responses, etc. This section will take a first pass look at the likely level of pre-existing complexity in our hypothetical hospital, assuming it has a functioning clinical HIS, HCIS and wireless Point of Care communications in place, and will look at how ECAS might be introduced in stages into such an environment. The roll-out shown here is not claimed to be the best one, just an existence-proof that a roll out of some type is possible.

As some of the analysis in the detailed drill down has shown the entire ECAS
infrastructure does not have to be in place before ECAS can provide a subset of its capabilities as services. This is illustrated in Section 16, by comparison of Figure 16-2, Figure 16-3, Figure 16-10 and Figure 16-8, showing steadily increasing interdependencies and complexities.

In addition the next section of this document explores an ECAS solution for a hypothetical mid-sized hospital and, in Section 8.5, covers at least one potential staged roll-out.

Nortel Confidential 110 of 226 8 An Implementation Case Study Covering Physical Infrastructure For A Mid-sized Hospital This section will examine a solution for a hypothetical mid-sized hospital of characteristics similar to the Antelope Valley Hospital characterized under 7.5 above.
The starting point will be to assume that this hypothetical hospital has deployed a modern mixed wired and wireless Hospital Information System, Hospital Clinical Information System and Radiology Information System and that its clinicians are making good use of those systems.

8.1 Basic infrastructure - Pre-ECAS
A high level view of the core infrastructure for the overall hospital information systems solution before the deployment of ECAS is shown in Figure 8-1, which is derived from Figure 2-3.

POC System ----------------------- --, Hospital Information System _- --Wireless POC W-Sec ~ ~--~ Hospital Clinical Radiotogy suB-sysfem ; Information Information POC Access System System = ' j ; =~ ; ~ , y 802.11 s steml ` ..
WLAN ~ i . . _. I

----- --------------------~
------ - - -------- ---------------- -^ Validating ^ Clinician ID, authentication = Clinician Clinician authenticated authentication, Clinician/
primitives access patient mapping ^ Terminal ID, type and ^ Authorized EHR data & = Routing and fetching data connectivity test results based on to/from various repositories ^ Patient ID clinician privileges, based on clinician requests ^ Requested information Patient ID ^ Order / workflow validation ^ Input data and orders = Order validation > Point of Care solution permits clinician to input or access data while with/near patient but can be cumbersome to use.

Figure 8-1 Wired & WLAN Point of Care Solution This comprises an overall Hospital Information System (HIS) which handles the non-clinical activities associated with the hospital information flow, the Hospital Clinical information System (HCIS), which handles all clinical and patient health data related activities such as PoC sessions, with the notable exception of the clinical information contained in the Radiology Information System (RIS) with its PACS network. The RIS
and HCIS are shown as two systems because that represents the generic reality -the RIS
Nortel Confidential 111 of 226 and its PACS network was likely to have been deployed within the Radiology Department long before the generic clinical IT became available throughout the facility with the creation of a facility-wide HCIS and hence the HCIS has to interface to and access the pre-existing RIS infrastructure if facility-wide radiology images are to be made available to the clinician population.

8.2 Basic Infrastructure-Post ECAS

Adding ECAS to this system results in a suite of more enhanced functionalities, as were explored in some depth in Section 7, but also results in some increased solution functional complexity and some added systems and sub-systems as is shown at a very high level in Figure 8-2.
...... ............... ............................
Environmental sensor networks.
- --Location, ID primitives network Rospitai Information System ~
----------------POC Systertt----,, Hospital `Clinica{ Radiology .~ ~ ~ v = Information Information Wireless POC ~L `l:
-,' -- System ----------- --, ls sub-system ; ;tl - ~ Sy em ----;
- -- ------------' Additionai ------------------------ ---------------------functions . - . [ :: h iJ ' i;"~ *L~ Y+~ f'=.~
. . .. - . . : . ... . . . . .
. ... :.: . . .. . .:. . . ...
..... . ... ... . :.. . s42 i K.:.:~.u. ..... .., . . = '.- . .
R1 Clinician Coord Location and Context R2 Patient tracking and/or monitoring ....... ... .........
R3 Equip't tracking, location & condition ....... ........ ......................
R4 Equipt/clinician, epuip't-atient assoc ...........
~
R5 Clinician Point of Care Communications Clinical Collaboration R7 Drug safety, sec'y and environment `'~'~ ~ ~ , E .-~;" ... ..,..... ~~..:;~=:~.~~~~~:~. - r ,: ;:
Regular workflow support and enabling functions Figure 8-2 Wired & WLAN Point of Care Solution With ECAS

An additional ECAS clinical services server function, actually likely to be a confederation of functions throughout the IT system, has to be created across the clinical access system along with the HCIS, HIS and RIS. All of these are also likely to require selective upgrades to their capabilities and functionality. In addition the clinical access system now needs a location detection and an environmental sensing capability, shown here as an environmental sensor network and a location and identification primitives Nortel Confidential 112 of 226 network and the core network needs the required data analysis and decision making functionality to turn the raw data from these networks into actionable information and decisions.. Some of the pre-existing server and database functions in the HIS, HCIS and RIS will need upgrading in either just software or in terms of both software and hardware, to handle the extra loads and processes.

The ECAS information flows from the server functions into the clinical access primarily to enable context and environmentally aware contributions, modifications, controls and enhancements to the clinical communication environment, whilst the ECAS server function inputs a suite of computed situational and environmental changes and decisions into the core network and is in turn fed inputs on policy, privileges, identities, shift changes, skills and other resource-based data, permitted associations, facility layouts, zones and maps, etc.

8.3 Solution overview This section explores how we might implement a pre-ECAS solution for a medium-sized hospital and how this would change or evolve as ECAS functionality is implemented. In both the pre-ECAS and post-ECAS examples the approach taken is illustrative in nature rather than a final optimized design and several alternative implementations will exist and will need exploring. Nevertheless the value of this work is that it allows the first visualization of the solution from a functionality, equipment, physical structure and topology and overall solution perspective although the software functionality and partitioning will need to be evolved and added. The parallel Disaster Response ECAS
activity is concentrating on these aspects and the expertise developed there was to have been mapped across into this set of solutions and scenarios. With the cessation of the ECAS team this is being deferred.

8.3.1 Solution Overview- Pre ECAS

Taking this very high level view further towards a preliminary implementation view, Figure 8-3 shows a possible pre-ECAS implementation of Figure 8-1. This infrastructure allows for extensive Point of Care communications using wired and wireless delivery throughout the facility and would have to allow seamless mobility between wireless nodes within the same wireless (WLAN) network.

Nortel Confidential 113 of 226 Figure 8-3 Example Pre-ECAS Hospital Infrastructure The system is blind to who is proximate to whom, whether equipment is being misappropriated, and other environmental and location factors, but does allow for real time interactive clinical support of clinicians at the Point of Care as well as clinician collaboration, with the attendant huge advantages of such a capability.

Applying this solution to the Antelope Valley hospital, as described in Section 17 we note that that hospital has 5 floors of areas: -- Floor 14 148,000 sq ft - Floor 24 97,000 sq ft - Floor 3--> 76,000 sq ft - Floor 4 (tower) 4 25,000 sq ft - Floor 5 (tower) 4 25,000 sq ft - Total 4 371,000 sq ft If the WLAN is designed around WLAN cells of 60' radius to allow for a good coverage, even if an AP should fail, then the approximate number of AP's required for full coverage would be: -- Floor 1........74 - Floor 2........49 - Floor 3........38 - Floor 4........13 - Floor 5........13 - Tota1.......... 187 For 802.11 b/g operation this would result in 62 AP's per orthogonal channel in a 3 channel plan or 47 AP's per quasi-orthogonal channel in a 4 channel plan, resulting an a significant likelihood of a serious Common Channel Interference (CCI) problem.
With 802.11 a, using 12 channels there would still be 15-16 AP's per channel spread over the 5 floors, although the separation of these AP's would be significantly greater and therefore Nortel Confidential 114 of 226 the Common Channel Interference could be much better managed but would require the use of 802.1 la-capable hand-held devices. A combined 802.11g/a roll out would result in 12-13 AP's per channel, a little better situation than for the 802.11 a case but requires dual mode hand-held devices.

The exact number of AP's required would be likely to be a little higher than this because of the effects of various building obstructions (e.g. elevator shafts, shielding in radiology areas) would create radio shadows that would require illuminating. Hence we would conclude that a tally of around 200 AP's would be required. Assuming that most users attach to these AP's at a modem PHY rate of between 24 and 54 Mb/s, then the average data throughput achievable per AP is of the order of 18 Mb/s (the data throughput is dependent upon such things as the packet length mix, but is in the ballpark of half of the PHY rate for a number of scenarios). This mean that the overall handling capacity of the 200 AP's in parallel is around 3.6 Gb/s or about 9 Mb/s per clinician for a 400 clinician facility. Of course one cannot load these AP's up to that rate - this is in effect a peak throughput rate and the average traffic would have to be 5-10 x less than that - but this still equates to 0.9-1.8 Mb/s per clinician as an equivalent continuous bit rate. This view is of limited utility until we can translate this into a clinician's need to receive certain sized packet-based transactions within a certain time window(latency) and in the presence of a background traffic load of other clinicians doing the same thing. This requires a workflow analysis that does not appear to have been done anywhere yet and hence is a possible subject for our academic program.

If the connectivity to the AP's is not to become a bottleneck then a feed of at least a 10/100bT Ethernet will be required. Hence each AP should home on to a port on a switch such as a Baystack 460, requiring around 14 of these to support the AP's (the theoretical number is a little lower but the partitioning of the building into 5 uneven floors and requiring two units per floor pushes up the count), combined withl6 Baystack 470-48T's to provide up to - 800 Ethernet jack appearances. These are run back into a pair of Passport 8600's to switch the entire traffic flows between the various AP's and Ethernet ports and the HIS, RIS and HCIS.

8.3.2 Solution Overview- Post ECAS

Figure 8-4 shows the extensions to the previous infrastructure required for an advanced ECAS deployment. This consists of four main areas being: -a) Extensions and upgrades to the Clinical Access Subsystem b) An overlay sensor and location network across the facility - this may be a series of physically separate overlays (e.g. sensor network, UWB location network) or may be a virtual overlay (e.g. WLAN location software added to the WLAN system) c) Upgrades to the core HCIS, HIS and RIS networks and especially to the functionality of various existing server functions Nortel Confidential 115 of 226 = ECAS infrastructure can be integrated with a conventional base = ECAS provides a new level of capability exploiting that base = A Clinical Grade result requires Clinical Grade for base and ECAS
Figure 8-4 Example ECAS Hospital Infrastructure The additional functions will be strongly dependent upon the required final capability. No completely satisfactory solution exists in technology today to simultaneously meet all of the needs of all of the services described earlier although some technologies and solutions are closer than others, and some of these have relatively small shortfalls.

For instance a UWB location system available today can achieve the level of precision required to provide the location component of all of the services described here but it cannot yet do this simultaneously with meeting the accuracy and latency components.
Nevertheless it is a very strong candidate and further maturing of this technology is happening. In addition combinational solutions such as proximity detection locally combined with a location system determining where that "locally" is may offer a good way forward for providing the location component of services where the location needs to be known to a lesser accuracy than the proximity - which is the case with many clinical applications.

Figure 8-5 shows a first pass layout for ultra-wideband receivers to provide location coverage across the first floor of our hypothetical hospital while Figure 8-6 shows the same for the second floor layout. Both floors use receivers covering one, two, three or four quadrants (which may be implemented as a receiver with an omni-directional antenna in the horizontal plane but may also be implemented as two 180 degree coverage receivers back to back or even four single quadrant receivers). The plan has been done of the basis of 70' squares as opposed to 80' squares that have been used where we have good visibility of the building infrastructure so can predict the required "fill-in" points, so as to allow a degree of conservatism.

Nortel Confidential 116 of 226 Figure 8-5 Possible layout of Receiver Nodes for a Floor-Wide UWB Location System - First Floor Figure 8-6 Possible layout of Receiver Nodes for a Floor-Wide UWB Location System - Second Floor Nortel Confidential 117 of 226 Measures of the system complexity can either be the number of required receiver nodes, significant because all of these have to be connected back to a central computation point and the number of receiver-quadrants, since this speaks to the number of single-quadrant receivers required.

This first rough plan of the first floor uses 69 receiver sites providing a total of 156 receiver quadrants (25 single quadrant, 23 dual quadrant, 7 x triple quadrant and 16 quadruple quadrant) while the second floor requires 52 receiver sites providing for 117 receiver-quadrants (17 single quadrant, 17 dual quadrant, 6 x triple quadrant and 12 quadruple quadrant). It is noted that the WLAN required 74 and 49 nodes respectively to achieve a high coverage on these floors so, given the similarities in numbers, it may be able to engineer a scheme to co-locate or even integrate the WLAN function and the UWB location function. Co-location would offer the major advantage of a common backhaul physical structure and hence less building disruption during installation, plus there might be other advantages, especially if both WLAN location and UWB
location are used, since a common set of coordinates can be used.

Functional integration may bring further benefits, including the possibility of a UWB
solution coexisting with WLAN in the same frequency band albeit with the UWB
using the entire 5-5.8GHz (so strictly speaking it would be semi-UWB) while the 802.11 a WLAN would still use 20 MHz channels. This may require an RF control plane across all AP's. Another alternative is to coordinate UWB and WLAN communications so that a UWB ping can precipitate a WLAN downstream transmission or vice versa, with the UWB ping slaved off of the WLAN transmission. Both of these would require the use of a WLAN receiver at the tag site which will dramatically increase power consumption.
This is a problem for personnel tags and other tags that have to run for long periods on the power of tiny batteries but is not such a problem in some other situations.

Hence the value of UWB-based location comes both from its greater precision, perhaps as good as 30 cm/1 foot in matured solutions (today's solutions can achieve this but not dependably), versus the multiple meters/10's of feet accuracy dependably available with WLAN. A dependable location precision of 30 cm/1 foot is at the outer limit of what is required for personal associations of clinicians with each other, with patients and equipment since their personal zone, dependent on circumstances, may only spread for 2-3 feet in front and to the side of them. The theoretical limit on resolution or precision is dependent upon the UWB RF pulse width and with pulses with an envelope half amplitude width of a nanosecond the resolution achievable is of the order of 6" to 1'. But at 7 GHz a 1 ns pulse width represents just 7 cycles of RF, so the power in the peak cycles needs to be reasonably high (it is 30-100 mW in some current designs) so that it is detectable by the broadband receivers. Here autocorrelation of the received waveform using an autocorrelation function that seeks correlation at the tag repetition rate can further lift the tag signal out of the background noise, but does so at the expense of system latency.

The use of 30-100 mW peak RF bursts is believed by some to be safe around medical instruments that are affected by the same power levels beamed at them continuously (or Nortel Confidential 118 of 226 with physiological rate periodicity) simply because of the extremely low average power levels from a UWB tag. For instance a tag transmitting 30 bursts per second ( a very high rate) at 100 mW average power during the 1 ns burst duration would be transmitting at an average power level of 0.1 x 1 x 10 exp-9 x 30 = 3 nanowatts, over a spectral width of perhaps 2 GHz for a power spectral density of 1.5 x 10 exp -18 watts per hertz. On the face of it these would appear to be very low power levels but there is an assumption here - that the medical instruments respond to average power levels. This will be validated (or not) as one part of a clinical information systems research program currently being launched at McGill University and the Jewish General Hospital, both in Montreal.

In addition sensors need to be deployed throughout the hospital. The buildings almost certainly have a pre-existing smoke detection and fire detection and alarm network, but these detectors are usually "dumb" and are of the type "smoke present/smoke absent" or "combustion products present/combustion products absent" and, in order to be sensitive enough to provide early detection of a real and dangerous fire they need to be sensitive enough that they can regularly trigger false alarms. The author was present when an over-toasted piece of bread in a student's toaster triggered the fire alarm system of McConnell Engineering Building, McGill University in November 2006 which resulted in a few hundred people having to evacuate the 8 storey building for 40 minutes and the rolling of fire appliances.

Therefore there is substantial room for improvement in fire/combustion/byproduct quantitative detection and calibration of the fire situation, both to massively reduce disruptive false alarms, while accurately detecting and evaluating fires in their earliest stages. This can be done with an array or grid of quantitative sensors (sensors which provide quantitative or value data, not just whether a preset threshold has been crossed) in conjunction with a level of video surveillance capability and smart context aware environmental aware processing in the core network. To do this it is likely that each room or space need be equipped with a suite of heat, light, combustion gas, smoke particle sensors, capable of real time measurement of the levels each of these that they are seeing at any time. This grid or array of sensors would have to be back-hauled through an access network. Since the majority of these sensors would be static they can be connected via a wired network or they could be powered locally and report back via a wireless network.
The type of wireless network would have to be assessed since even these sensors produce data in short bursts and both WLAN's extremely low efficiency in handling short packet traffic (the same problem that makes it inefficient for VoIP) and its complex protocols adding too much complexity and power bum at some sensor sites (especially the subset that are mobile and may have to run off of batteries for weeks or months) make it unsuitable for this application.

So we will assume that our hospital has deployed a state of the art wired array of sensors into every room and every major space (halls, corridors, atriums, etc.) Unfortunately the level of data available on our hypothetical hospital does not allow for an accurate room/space count to be made but a first estimate can be made. Figure 8-7 shows a first very rough assessment of number of sensor sites required to provide an intelligent but coarse monitoring for fire presence, severity and type.

Nortel Confidential 119 of 226 Figure 8-7 Approximate fire sensor locations -hypothetical model hospital Even this coarse view requires about 180 sensor sites on the first floor alone and the real number may be more like 400. A quick check in a local hospital (Queensway-Carleton, Ottawa) showed that fire detector spacings were in fact more like 20 feet apart, which would result in significantly more sensor locations being required. So how to get the data back from these sites? A home run cable or bus (daisy chain) wiring infrastructure could be used but putting wiring into operating hospitals, especially at this scale, is very expensive, since the areas of the hospital that have walls or ceilings open have to be closed down. Alternatively the sensors could be locally powered and report back to a central processing point via a wireless technology. The question then becomes what wireless technology. The overheads of WLAN and its inefficiencies when carrying small packets tend to preclude it, so the options would be: -a) A new wireless sensor-optimized protocol and technology- this could be a simple as a WLAN with a new MAC layer or something completely different b) A short range, Bluetooth like technology to link the sensors back to local hubs which themselves are backhauled on a WLAN. This would avoid the sensor short packet problem and protocol complexity problem because the hubs, at perhaps 1 per 10 sensors, would provide a level of buffering and consolidation of sensor Nortel Confidential 120 of 226 data and could afford to operate with a WLAN protocol - at least that would be the idea. But the short range would have to link to the sensor hub and if the sensor hub ends up being 75 feet away from the furthest sensor then the RF problems and ranges are similar to a WLAN and the link from the sensor to the hub starts looking like a slow WLAN link with a new MAC.

However, by having all these sensor locations report the quantitative changes in smoke particles, combustion byproduct densities and compositions, temperatures, real time illumination levels, etc. back to a centralized ECAS context processing point a much finer detailed view of the cause of the problem readings can be ascertained and the appropriate action taken instead of the necessary over-reaction when the scope of the problem is not known. Furthermore these sensor nodes, along with other sensor node locations as-needed, could detect the presence of other chemicals or gases which can be associated with Hazardous Materials Releases. This capability would be concentrated in areas where chemicals/hazardous materials are stored, or are used - for instance natural gas detection equipment and carbon monoxide detection equipment would naturally be placed in the facility's furnace room (if it had one) but may not be used elsewhere.

But besides providing early warning of fire and HMR's and then helping to track them, sensors have a number of significant roles to play in the normal day-to-day operations.
The areas where sensors can assist operations include: -a) Hospital operations i. Detection of people ii. Monitoring building condition and operation iii. Monitoring equipment condition and environment iv. Etc.
b) Clinical operation i. Patient parameter monitoring (via sensors or via telemetry from existing but now wireless connected equipment or both) ii. Clinical equipment environment and condition iii. Patient environment monitoring iv. Etc.
8.4 Numerical model The first rough view can be formed of the size and scope of the infrastructure required throughout the facility of the hypothetical model hospital. This is shown in Figure 8-8.
The numbers of staff are the clinical staff on duty during the day shift, assuming that the day shift is substantially more active than the night shift - this is usually the case in most hospital departments although there are some notable exceptions. Besides the clinical staff, there will be around 400-500 other employees on shift during the day and a lesser number at night.

Nortel Confidential 121 of 226 The hospital can be serviced by a WLAN with a capacity of around 200 AP's for a dense, high coverage deployment - about half this number would give a reasonable "best effort"
coverage but not one suitable for clinical purposes. About the same number of precision location receiver nodes or sites is needed but studies have not yet been done to see if the two technologies could be merged and the receiver sites collocated, using a common backhaul - this would significantly reduce the cost of a precision location overlay and reduce the entry barrier for ECAS. If the clinical staff, patients hand-held devices and portable/movable medical equipments are all `wearing" UWB pingers or tags, then the number of active tags at any one time during the day shift is around 1,200. If the non-clinical staff also have these tags and 30% of them have hand-held devices then this number will increase to close to 2,000.

1,500 major clinician-patient events 5,400 minor clinician-patient events Each event can 2,800 clinicianclinician events of degree 2.2 involve multiple Many other events transactions Figure 8-8 Approximate numerical dimensioning of hypothetical hospital Calculations included in Section 13 - Appendix gave us a first insight into numbers of clinician-patient and clinician-clinician encounters per day. Assuming that the majority (75%) of these were to occur during the 8 hours of the day shift then the clinical event rate would be around 900 per hour.

A much more detailed and refined model of the hospital network and the events it supports and transactions it carries needs to be developed. This is intended to be a part of the upcoming academic healthcare research program.

Nortel Confidential 122 of 226 8.5 ECAS Solution Roll-Out Example The ECAS final solution shown in Figure 8-4 earlier showed the implementation of a complex system with huge capabilities. In fact the ECAS approach will allow various subsets of those capabilities to be deployed in various roll-outs. One example roll-out is given here without any claim that it is either the best roll-out or the only roll-out. It is an example roll-out.

The pre-ECAS situation is shown in Figure 8-9 which is similar to Figure 8-3 and assumes a hospital with a modem WLAN network, clinicians making use of that network for clinical information and collaboration and a hospital infrastructure to suit. In fact this is only the case in the minority of hospitals with most hospitals having plans to reach this stage in their evolution either imminently or in their near future.

Figure 8-9 Example ECAS Hospital Infrastructure - Pre-ECAS

The first step of this particular ECAS roll-out is to add WLAN-based location and the necessary context processing and location processing to allow non-clinical use of the capability provided. This is shown in Figure 8-10 Nortel Confidential 123 of 226 = ECAS context infrastructure in HIS plus WLAN software-based location = Capability - basic equipment, WLAN transmission location within 3-5 meters to find equipment, people at room-level granularity, basic asset tracking, theft detection Figure 8-10 Example ECAS Hospital Infrastructure - WLAN Location integrated into Non-Clinical Services Figure 8-11 shows the solution when expanded into a subset of clinical services. At this stage the solution cannot provide quality clinician/patient or clinician/equipment associative services due to the poor resolution and accuracy of the basic location information = ECAS infrastructure further extended into Clinical services domain = Provides clinicians with that subset of services which can exploit room-level location granularity (not associative services) while retaining non-clinical services Figure 8-11 Example ECAS Hospital Infrastructure - WLAN location integrated into non-clinical and selected clinical services The addition or substitution of an Ultra Wide Band location system or some other form of high precision location or location/proximity sub-system will allow location-aware Nortel Confidential 124 of 226 services to be extended to associative services - this is shown in Figure 8-12 for UWB
substitution and Figure 8-13 for the expansion of services = Replacement of WLAN location with UWB (or another precision location/proximity technology) allows associative services = Ciinicianlequipmentlpatient associative services and other high precision services all become viable Figure 8-12 Example ECAS Hospital Infrastructure- Substitution of UWB location = Suite of services expanded throughout clinical, non-clinical domains Figure 8-13 Example ECAS Hospital Infrastructure - Full suite of Location -Aware functions This can be followed (or could have been preceded) by the addition of a Sensor grid and the necessary context processing to allow Building Automation and/or sensor-based services to be available across the facility. This is shown in figure 8-13, which is similar to Figure 8-4 Nortel Confidential 125 of 226 = Sensor network provides building automation, threat detection, management capabilities, added non-clinical and even clinical services Figure 8-14 Example ECAS Hospital Infrastructure -adding the sensor-based senses While this is one example roll-out multiple variants are possible, depending on specific situations and needs. In particular the sensor-based aspects, added at the end in this example roll-out, could have been added much earlier or even could have been the ECAS
starting point.

8.6 Issues and areas for investigation There are a plethora of issues to be worked through, both in the context/server/software/
solution architecture and in the simple basics of the physical infrastructure.
Following on from the dimensioning exercise of the last section the following are some of the basic areas that will need to be investigated mainly in the physical/equipment layer.

These are: -- Clinical Grade WLAN - Can we establish a definition for adequate WLAN
coverage to meet Clinical grade availability and the design tools to achieve this?
- Can WLAN (802.11 alb/g/n) actually achieve an adequate performance?

- Is precision location more attainable than precision proximity from a solution perspective and is it more valuable from a clinical application perspective?

- Can Ultra Wide Band location simultaneously achieve adequate precision, accuracy and coverage to meet Clinical Grade objectives?

Nortel Confidential 126 of 226 - Can UWB and WLAN resources, notably the receivers, be physically coordinated or integrated and can they use a common backhaul technology?

- Clinical traffic - can we build a better model of clinical workflows and their information requirements? What are really the key parameters we need to be concerned with? (Throughput, coverage, latency, bandwidth, transaction rate??) - How will the Clinical traffic levels change and what will change and how, as clinicians adapt their workflow practices to exploit these capabilities??

- Security -how will the hand-held terminals and the sensitive clinical data both they and the network carries be protected? Will the proposed security and ECAS
theft protection/detection approaches prove adequate and sufficient? Can biometrics help? - E.g. as a reader in the employee badge.

- Powering - will hand-held short power-life become a show-stopper? What can we do to alleviate the problem? Will location tag battery life (and employee tag battery life) become an issue?

Besides these issues there are a whole suite of issues around the Context portion of the ECAS solution, including staff, clinician and patient privacy and information protection, information architectures and flows, security and protection against data theft or data tampering, reliability and dependability architectures, meeting the strictures of HIPAA, PIPEDA, etc. etc.

Nortel Confidential 127 of 226 9 Extending solutions to other sites The principles discussed and presented here can be extended to other areas in healthcare as well as outside of healthcare, as the disaster response work has amply shown. The purpose of this section of this document is to capture an initial perspective on other areas in Healthcare that could benefit from the application of Clinical Grade IT
solutions, with an ECAS component.

These areas may use very similar or very different implementations and solutions but will all use the underlying principles of the Clinical Grade tenets and of the ECAS
ideas and concepts 9.1 Large hospitals, small hospitals These are logical extensions from the medium sized (300 bed) hospital analyzed here.
In larger hospitals the major differences arise in the details of the scaling up process plus the recognition that larger hospitals are more often multi-building or even multi-campus so ways to allow context flow across these conditions need to be found. This will probably require a seamless solution migration between WLAN and cellular wireless at least for the multi-campus situation.

Smaller hospitals cannot be addressed simply by scaling the system down although this goes part way. An overall simplification, perhaps removing some of the more sophisticated functions will be required too to achieve the right economic point. However the Clinical Grade aspect must not be compromised. Neither should the ECAS
component be degraded. There is a further area that needs to be added, especially for the very smallest hospitals; that of external clinical consulting. A small hospital with maybe physicians and 20 nurses on-shift will not have the senior clinician expertise necessary in complex or rare patient treatments so the options exist to export the patient to a major center or to import the necessary specialists. To this a third alternative, that of virtual importation of the specialist or virtual export of the patient can be added through the use of multimedia clinical IT and it is anticipated that the use of ECAS can substantially further this process.

9.2 Reaching out to the clinic and physician office This takes the ECAS and Clinical Grade solutions into clinical practices so small that a linear extrapolation of the example medium hospital case becomes meaningless.
A
completely revised solution, still meeting Clinical Grade requirements and ECAS
attributes is required. The nature of the Clinic and Physician's Office and its roles and its interfaces with the rest of the healthcare system must be recognized. While the hospital was largely self-contained and was of a large scale the Clinic and in particular the doctor's office are small sites that outsource a lot of clinical activities to test labs, Nortel Confidential 129 of 226 pharmacies and to hospitals. Hence system integration becomes important, and in more and more cases specific physician's offices or clinics are becoming affiliated with specific hospitals, leading to a need to integrate into that hospitals IT
solution, hopefully its Clinical Grade ECAS solution without overburdening the clinic or physician office with cost, equipment or operational complexity. Hence a solution that meets these needs, applied the values and standards of excellence of Clinical grade and ECAS is required, but also a solution thought through from the ground up for this application -not a cut down hospital application.

9.3 The mobile clinician Once clinicians are using Clinical Grade solutions using ECAS and have evolved their workflow to become dependent upon ECAS within the hospital and perhaps also within their office or clinic it is likely that maintaining some type of clinical IT
functionality, with the same attributes, would be a desired capability by the clinician community. For instance a cellular wireless connected tablet PC with the right software and system infrastructure would allow a clinician sitting in a secluded corner of a restaurant with his wife and 16 year old daughter to be enjoying a 16th birthday dinner together, even though the clinician has a critical patient; he is monitoring the patient condition regularly, every 15-20 minutes and can be contacted at a minutes notice if necessary - but all of this is virtually unobtrusive into the family celebration. I had a demonstration of just such a capability while in New York recently albeit without the birthday celebration and without ECAS or CG attributes.

9.4 Home healthcare applications and solutions Home healthcare breaks down into two classes of care with very different needs. One of these is hopefully short-term and the other is often longer term, long term or for the full remaining period of life.

The short-term home care comes about either as some form of care at home (either self-administered or administered by a visiting caregiver) prior to a hospitalization event or, more commonly, after a hospitalization event, as part of the recuperation process - the basic principle being that the earlier a patient can be got back into their home setting the better they will do psychologically and often clinically as well. But for this process to be applied earlier and earlier there are increased risks, those associated with early stage recovery from the patient's condition and/or hospital treatment. This will require more intensive monitoring of the patient condition at home. As to how this can be done has not yet been investigated by the Healthcare ECAS team.

The other form of home care is for those who have a medical condition which is either stable or in a long-term decline for which hospitalization cannot bring any viable clinical improvement - this may be due to age, an incurable degenerative disease, a disease that Nortel Confidential 130 of 226 has passed by the point where clinical intervention was viable or may be a long term disability caused by a wide range of things. This requires a long-term solution that may be in place in the patient's home for weeks, months, years or even decades, which allows for a scope of solutions which is very different to the short term case (e.g.
monitoring a patient for the first week home after major surgery. This area is one being addressed by Prof. Rafik Goubran and Dr. Frank Knoefel of the E-B hospital in Ottawa and we are linked to their program. It is intended that this program will be brought into the ACHE
research project framework in 2007.

Nortel Confidential 131 of 226 Next Steps This document reports on a very broad and substantial piece of work.
Nevertheless we are still at the point of opening up more questions than we are finding answers and we are likely to be doing that for a while in this space. Hence we have to apply some structure and discipline to our next steps so we can both start to realize on near-term commercial opportunities within Nortel and its customer base while also developing the deep understanding necessary for the maximum long-term benefit and advantage.

To that end the next steps break down into three groups. These are: -a) Nortel- what next steps does Nortel need to take in this space?

b) ATR / CTO and the internal research community - what steps do they need to take to ensure maximizing Nortel's near-term opportunity while also providing long term guidance and an impedance/control on the academic program c) Academia and University-type research - what do we need to establish in order to develop the right long-term and strategic connections, assets, capabilities, and skill-sets The next steps must take into account the current situation. The key aspects of the current situation are: -1) There is not enough internal funding and resources available to carry this work forward in an internal program with adequate critical mass 2) The formation of a Healthcare Solutions group with a real ability to engage the market, albeit with nearer term solutions, gives this work and direction increased value to the corporation because the channel to market path is now becoming much clearer 3) There is need for much research and concept validation before we can move this forward- this needs to be done in collaboration with clinical researchers and clinical IT researchers in universities, and with forward-thinking hospitals The Healthcare industry itself is recognizing that, after a long period of resisting change in clinical processes and the adoption of IT into those processes, it is time for change, and a momentous change has been occurring in Healthcare and Healthcare Clinical It for the last 4 years and will continue for the next decade or more.

So, armed with these perspectives, let's look at the three areas - Nortel, ATR/CTO and Academia.

Nortel Confidential 133 of 226 Nortel Nortel, specifically the Healthcare component of the Solutions Business may want to assess the opportunities that applying ECAS into a Healthcare environment might bring.
The working assumption that triggered the work reported on here was that an ECAS
infrastructure and capability could impact clinical workflows in a highly positive way -this has been the theme at our last three appearances at the HIMSS healthcare conference and trade exhibition. We now need to determine what aggregated solution components we have in our current and POR portfolios to allow the start of a phased roll-out in this space, along with assessing what functions and capabilities we will need relatively soon and which functions and capabilities can be deferred at least for a while. We also need to look at our upcoming new capabilities over the next 12-24 months, as captured in the POR and POI's of the company and see whether this provides incremental functionality and capability in this space and conversely where holes will still exist.

The Solutions team may also want to assess whether the advantages and capabilities offered by an ECAS-like solution give us an advantage which will allow us to forge a mutually beneficial alliance or partnership with one or more of the major Healthcare Systems integrator companies - companies like Cerner, McKesson, Misys, etc.

A series of white papers and other publications may need to be developed and the material contained herein may allow some of that process to commence. In addition there may be the need to develop a solution demonstration platform or at least a technology evaluation/verification platform for key parts of the solution - this may well use resources from the Solutions team or may use ATR resources.

ATR/CTO
ATR will need to continue to engage the rest of the company, notably the healthcare component of the Solutions team and the Healthcare Vertical Marketing team (HVM), with the vision, solution, and capabilities offered here. It should support the Solution team activities to bring prospective customers to the table to assess and critique these opportunities and solution elements.

ATR should also continue to support the current efforts and activities of the Solutions team in this space, as they are doing for HIMSS07. however, as the Solutions team builds its capabilities it can take over the role of providing demonstration capability to conferences such as HIMSS, allowing ATR to return to an innovative technology and future solution exploratory role.

In addition ATR should either conduct or lead research in a number of areas in this space or alternatively trigger academic research, especially academic engineering/clinical cross-disciplinary research in this space. A number of academic projects are already under way and ATR should drive to coalesce these and other new starts into a broad healthcare Nortel Confidential 134 of 226 program focused at the medium and long term needs of the corporation. Subject to differing opinions from the Healthcare Solution team, the focus of these should for the time being remain the medium sized hospital, since we need to complete our understanding there before moving on. At a future point we will need to extend the architectural work beyond medium sized hospitals into large and small hospitals, hospital groups, clinics and MDB's and even into home healthcare.

ATR may also need to drive some Standards work, notably in the area of evolving n updated more detailed view of Clinical Grade, of incorporating Clinical Grade standards into ECAS and incorporating ECAS into Clinical Grade - both impact the other.
We also need to assess the fit and interaction of ECAS with existing purely clinical standards such as HL7 and possibly DICOM, perhaps by an internal program or perhaps at least partially through an academic research program.

Lastly but not least ATR should continue to mine this space for any more "nuggets" of IPR that may prove useful for future solutions.

Academia An overall academic program consisting of a number of academic projects and thrusts could be launched as a way to externalize some of the work needed in this space. Areas that might be suitable for inclusion in such a program would include: -- Clinical Research areas and topics, especially topics with high communications content or relevance. Key amongst these are topics such as: -o Developing better views and models of hospital clinical workflows, both for the present (where they can help quantify the design of near-term Clinical grade Solutions) and longer term, incorporating the functional impact of ECAS deployment into the clinical workflow, and using this to develop both near-term and long-term traffic models o Testing the concepts for revised workflows and ECAS impacts on the clinical community and incorporating clinical feedback into the concept - Clinical/communications standards such as; -o Supporting the evolution of Clinical Grade and understanding the relationship between Clinical Grade functionality being achieved and ECAS helping to achieve it.

o Testing aspects of the Clinical Grade definition on the clinical community Nortel Confidential 135 of 226 - Architectural work, especially ECAS architectural work addressing clinical applications and scenarios o Developing a deeper understanding of architecting HIS and HCIS
functionality with ECAS principles and solutions o At a future point extending the architectural work beyond medium sized hospitals into large and small hospitals, hospital groups, clinics and MDB's and even into home healthcare.

o Develop view of dimensioned core network architectures based upon future traffic models and future workflows o Identify key architectural issues and identify potential solutions - e.g.
how to handle fraudulent or counterfeit tags - Engineering research in both software solutions and infrastructure and in the alternatives for the physical layer and hardware infrastructure, which may determine the deploy-ability of some solutions o Understand the requirements for templates to fit into clinical functions and where there are existing standards, protocols and procedures -then how ECAS templates can either align to these or evolve them o What are the clinical applications or the clinical supporting applications which Nortel can provide (as opposed to an HSI).

o Explore key physical layer questions such as the trade off between precision location and proximity detection at the solution level, the achievable performance of WLAN, UWB and whether these can be Clinical grade components, and whether WLAN and UWB or other location/sensor-friendly technologies can be integrated for amore cost-effective solution.

o Longer-term work in advanced wireless mobility beyond work already under way within ATR, should this prove necessary o Evolution of clinical hand-held technology - at the solution, system, hardware, software level, including security, usability, user needs and preferences, etc. (This may come through the M3 program) An opportunity has arisen to launch a new university Research Network (a network of academic researchers, not a physical communications network), modeled on the successes of AAPN (Advanced Agile Photonic Networks), but in a new area, that of Advanced Communications for Healthcare Enablement (ACHE). Research Networks are research projects of sufficiently diverse and interactive characteristics that it is necessary Nortel Confidential 136 of 226 to pool the research talents and knowledge of multiple diverse researchers in multiple universities and such networks can be the recipients of significant government body funding, the AAPN one receiving $7Million over 5 years from NSERC as well as the source funding and in-kind funding from its industrial sponsors. ACHE
qualifies as a research network under this definition and work is already under way between 3 universities plus Nortel's ATR group to create an appropriate project definition to allow us to go forward for NSERC funding under their nest call for proposals which will be next June (June 07). This would lead to a research network being founded and starting research in early 2008. This is too far into the future so we are "corralling"
our current research initiatives and adding some small additional seed funding, plus funding from tactical sources to start academic research in this space during 1Q07, which will take 12-15 months off of achieving our first results in this area.

More information on this new Research Network will be made available as the team is formed.

To complement this the generic capabilities of smart, context aware network technologies must be kept alive and growing within Nortel and the majority of the ECAS
program team will be absorbed into the CASS program where this activity will reside.

Nortel Confidential 137 of 226 11 Glossary A
AAPN Agile All-Photonic Network ACHE Advanced Communications for Healthcare Enablement ACK Acknowledgement AI Artificial Intelligence A-GPS Assisted Global Positioning System ADE Adverse Drug Event ADR Adverse Drug Reaction aka Also known as AP Access Point ATR Advanced Technology Research B

BA Building Automation BC Business Continuance BC/DR Business Continuance/Disaster Recovery BPEL Business Process Execution Language C
CASS Context Aware Seamless Services CCI Common Channel Interference CG Clinical Grade CoS Class of Service CPOE Computerized Physician Order Entry CRS Contest Responsive Solution CT Computerized Tomography CTO Chief Technology Officer D

DR Disaster Recovery E

EAN Environmentally Aware Network EAS Environmentally Aware Solution ECAS Environment and Context Aware Solution ECG Electrocardiogram EHR Electronic Health Record EMR Electronic Medical Record Nortel Confidential 139 of 226 EMS Emergency Medical Services EMTALA Emergency Medical Treatment and Active Labor Act EPR Electronic Patient Record ER Emergency Room F

G
GDP Gross Domestic Product GHz GigaHertz (1,000,000,000 Hertz) GPS Global Positioning System H
HCIS Hospital Clinical Information System HIMSS Healthcare Information and Management Systems Society HIPAA Health insurance Portability and Accountability Act HIS Hospital Information system HMR Hazardous Material Release I

ICU Intensive Care Unit ID Identity IPR Intellectual Property Rights IR Infra Red IT Information Technology J

K
Kb/s Kilobits/per second (1,000 bits per second) L

LAN Local Area Network LTE Life Threatening Event M

MAC Media Access Control Mb/s Megabits per second (1,000,000 bits per second) Nortel Confidential 140 of 226 MDB Medical-Dental Building MHz Megahertz (1,000,000 Hertz) MRI Magnetic Resonance Imaging mW MilliWatts (1/1,000 Watt) N
NACK Negative Acknowledgement NSERC National Science and Engineering Research Council NY New York OR Operating Room P

PACS Picture Archiving and Communication System PANYNJ Port Authority of New York and New Jersey PC Personal Computer PDA Personal Digital Assistant PET Positron Emission Tomography PHY Physical Layer PIPEDA Personal Information Protection and Electronic Document Act PoC Point of Care PoC/PES Point of Care/Patient Entertainment System PoD Point of Decision POI Plan of Intent POR Plan of Record Q

QoS Quality of Service R

RF Radio frequency RFID Radio Frequency Identification RIS Radiology Information System S

SARS Severe Acute Respiratory Syndrome SLA Service Level Agreement SMB Small and Medium Business SOA Services Oriented Architecture Nortel Confidential 141 of 226 SSID Service Set IDentifier T
U
UK United Kingdom UML Universal Modeling Language US United States USA United States of America UV Ultra Violet UWB Ultra wide Band V

VoIP Voice over Internet Protocol w WLAN Wireless Local Area Network WAN Wide Area Network x XML Extensible Markup Language Y

z Nortel Confidential 142 of 226 12 Bibliography The following is a partial bibliography of healthcare and ECAS-related antecedent publications from the ECAS team.

Title Format Approx Date Requirements, Architecture and Implementation of Point Of Presentation Care solutions Mission-Critical Communications To The Point Of Care -The Presentation Vision Nortel In Healthcare...........A perspective on an o ortuni Presentation Wireless Location Services and Healthcare Applications PDF Report 3/12/2004 Wired Point of Care and Patient Services: System PDF Report 5/19/2004 Description and Network Requirements Location Service Platforms for Enterprises PDF Report 7/12/2004 Healthcare-Delivering growth through industry focus - Presentation 7/19/2004 submission to IRB - version 28 Wireless Point of Care: System Description and PDF Report 12/15/2004 Requirements WLAN Trial for Healthcare - Interim Report PDF Report 6/7/2005 WLAN Trial for Healthcare - Location Technologies: Ekahau PDF Report 6/10/2005 Results WLAN Location Based Technology Input PDF Report 7/14/2005 WLAN Trial for Healthcare - Location Technologies: PDF Report 7/20/2005 Trapeze/Nortel 2300 - Norte12200 Interworking Results Clinical Grade - A Foundation for Healthcare Paper 8/16/2005 Communications Networks - DRCN 2005 Clinical Grade - A Foundation for Healthcare Paper 9/14/2005 Communications Networks - 12 Healthcare Solution Business Proposal - V27 Presentation 10/24/2005 Concepts for Context and Environmentally Aware Solutions: PDF Report 2/7/2006 Clinical Applications Focus Environmental & Context Aware Solutions Selected Presentation 4/24/2006 Applications Overview Collaboration Scenarios - A review of GE Medical / Nortel Presentation Opportunities Hospital ECAS Application Scenarios and Required Presentation 6/29/2006 Capabilities - Version 11b ECAS Architecture - Single Building Hospital - Version 1 Presentation 7/4/2006 Emergency Code Calls Response via Contextual Inputs: PDF Report 10/5/2006 Model Scenario Description and Rules Nortel Confidential 143 of 226 13 References Ref 1 Institute of Medicine. "To Err is Human, Building a Safer Health System". Kohn LT, Corrigan JM, Donaldson MS, Eds. National Academy Press, Washington, DC, 1999.

Ref 2 Computerized Physician Order Entry, Joe Miller and Arthur Eskew MD, Workshop B, HIMSS 2003 Ref 3 The Canadian Adverse Events Study: the incidence of adverse events among hospital patients in Canada - G. Ross Baker, Peter G. Norton, Virginia Flintoft, Regis Blais, Adalsteinn Brown, Jafna Cox, Ed Etchells, William A. Ghali, Philip H6bert, Sumit R. Majumdar, Maeve O'Beirne, Luz Palacios-Derflingher, Robert J.
Reid, Sam Sheps, Robyn Tamblyn - JAMC, May 25, 2004 Ref 4a "Queens Health Network - Healthcare Information System 2002 Davies Award Winner - A Model for an Integrated Computerized Patient Record", Carr, David and Rothschild - Presented Paper HIMSS 2003 Ref 4b "Queens Health Network - Healthcare Information System 2002 Davies Award Winner - A Model for an Integrated Computerized Patient Record", Carr, David and Rothschild - Electronic Poster Paper HIMSS 2003 Ref 5 Computerized Physician Order Entry, Joe Miller and Arthur Eskew MD, Workshop B, HIMSS 2003 Ref 6"Collaboration Scenarios - A review of GE Medical / Nortel Opportunities"
-Presentation- Feb 2005 Thomas Chmara Ref 7"Clinical Grade - A Foundation for Healthcare Communications Networks"
DRCN 2005, Ischia, Italy, October 2005, Alan F Graves, Bruce Wallace, Shalini Periyalwar, Carlo Riccardi Ref 8 Nortel ATR Document "Concepts for Context and Environmentally Aware Solutions: Clinical Applications Focus" - Jeff Fitchett and Alan Graves, Feb Ref 9 Nortel ATR Document - "Environment- and Context-Aware Solutions -Program Prospectus Release 1.0" May 2006 - Author ECAS Team - Thomas Chmara Guy Duxbury, Jeff Fitchett, Alan Graves, Jodee Varney, Brian Vezza, John Watkins Nortel Confidential 145 of 226 Ref 10 "Environment- and Context-Aware Solutions - System Architecture: With Focus on Port Disaster Scenario, Thomas Chmara, John Watkins, Guy Duxbury, and Brian Vezza - November, 2006 Ref 11 "Concepts for Context and Environmentally Aware Solutions: Clinical Applications Focus", Jeff Fitchett, Alan Graves, Internal Document, February 7, Ref 12 "Wireless Location Services and Healthcare Applications", special handling document, Jeff Fitchett, December 3, 2004 Ref 13 "WLAN Location Based Technology Input", Kent Felske, Hesham Elbakoury, Jeff Fitchett, Internal document, July 14, 2005 Ref 14 (was JF 1) Ref 15 (was JF2) Nortel Confidential 146 of 226 14 Appendix - Basic Functions and Requirements For Selected Major Routine Application Areas This appendix will explore multiple "routine" applications across the spectrum from "independent of clinical practice" to "clinical practice-enabling". They will be presented from a perspective of their communications functionality.

14.1 Clinician Coordinates Location And Context The objective of this application is to provide accurate, low-latency, unobtrusive identification of clinicians' location, strictly as a private and confidential input to computing the clinician situation, needs and nature of more clinically involved services that are required to support clinical workflow integrated, or workflow enabling applications being used by the tracked clinician. As such this is a service providing input parameters for other more sophisticated services. The attributes of this service are: -a) Widespread use throughout hospital in locating and tracking clinicians - a high degree of facility coverage is required in areas of the facility where tracking is appropriate and no coverage where tracking is not appropriate.
This may be achieved at the physical level or by appropriate filtering of the location and identification data before release to other user applications.

b) Provides a location and optionally an implied context aspect to automating the optimization of multiple services, both in and beyond communications c) Provides a basis for several other services due to the ability to track the clinician's location d) The time criticality requirements of client services supported by this service are transferred through as requirements on this service. The time discrimination (latency) of this service must meet the needs of client services based on the location tracking capability.

e) Precision and accuracy - the location precision and accuracy requirements of the services this service supports transfer through as requirements on this service. Different supported services have different requirements - for instance a service that is establishing which wing of the hospital a clinician is in may have a precision requirement measured in 10's of feet or more and an accuracy requirement of 95%, whereas a supported service that involved delivering private data to a terminal based purely upon the terminal being within the clinician's personal zone may have precision requirements of+/-12 inches and an accuracy in the 99.99-99.999% range - a very tough or impossible target to meet, mainly because of the accuracy required.

Nortel Confidential 147 of 226 f) Located entity discrimination and identification - in a multi-entity environment the service must be able to accurately track multiple entities and discriminate their locations and identity primitives - it does not need to know each entity's real world name but must be able to identify teach entity's location identifier, so that can also be passed to the higher level supported services, which can map the location identifier to the corresponding real world identity, permissions, profiles, etc.

g) Security - This application should be able to confirm the identity of tracked clinicians and report location and identity only to authorized user applications for this information - there are significant privacy issues and intrusion of personal space issues if the information is not correctly used.

h) Dependability - Higher level applications must be able to depend upon the information provided from this application, including latency, accuracy and precision of tracking and tracking the correct entity in an entity-rich environment (a crowd).

Hence the value of this solution is the ability to provide real time location-based support to other services including Clinical Point of Care communications, Clinician to clinician communications, clinician telecommunications reconfiguration, equipment theft protection, equipment maintenance, etc. Location/situation optimized services are anticipated to improve user satisfaction with the services that rely on this service, user proclivity to use those services as well as the ease-of-use of those services while also protecting the user and facility from data theft, equipment theft, and inappropriate access to data. But this can only be realized if the user has no concerns about misuse of his/her location information, either by the hospital organization or third parties, requiring that data information be regarded as information to be kept private and secure.

The inputs, outputs and functions for this service at both a basic (support to other services only) and more sophisticated (stand alone utility) variant are given in Figure Nortel Confidential 148 of 226 a) Basic location service for input to other services Inputs Outputs Environment Functions = Location vector primitives Clinician location and tracking from location subsystem }___*
(clinician) Processing of raw data to = Clinician location = ID primitives from location determine clinician location, subsystem (clinician) vector b) Rich stand-alone location service Inputs Outputs Functions Facility information = Hospital grid map, zone Clinician location and map and usage allocation context tracking I = Clinician location and Context mapping to functional = Clinician ID's - Processing of raw data to area of facility = Each parties terminal type determine clinician location, = Location context input and connectivity -~I vector to other applications, = Mapping of clinician's role including context to zone, either generic or Establish clinician zone history specific to clinician ID % presence as input to clinician Environment context = Location vector primitives (clinician, terminal) J Establishing hiStory of location Validating clinician is at location Figure14-1 Clinician coordinates location (RI) The ECAS contributions and enablers are: -a) The Clinician location tracking capability of ECAS, from the location component of its sensor network provides input to location-sensitive services, assists in providing context-aware capabilities, which include physical world location, both to grid and by zone.
b) Location-based context awareness leads to better context-interpreted responses which in turn allows for more effective, speedier, convenient clinician support services and a higher clinical productivity with lower clinical error rates Key environmental parameters that ECAS has to discriminate for this service are: -a) Clinician location b) Clinician terminal location c) Clinician identifier and validation d) Clinician terminal identifier and validation Key Context parameters that ECAS has to discriminate for this service are: -a) None for a basic location service - context is supplied by higher level services supported by this service (Option a) in Figure 14-1) b) Alternatively, in a rich location service context would make use of a Hospital map of functional zones and uses, Clinician ID, type and capabilities of hand-held terminal. The basic service will be assumed here since we are also examining the Nortel Confidential 149 of 226 suite of supported services and adding sophistication to this basic service would only duplicate functionality (Option b) in Figure 14-1) 14.2 Patient Tracking And/Or Monitoring The objective of this application is to provide tracking of the physical location of patients in a private and confidential manner strictly as input to other supported services and to alert staff on a need-to-know basis. The objective of this application is to provide tracking of the location of either all the patients in the hospital or alternatively some groups of patients within the hospital, based upon the needs of the supported higher level applications. This application will have to exhibit accuracy, precision and latency compatible with the needs of those higher level applications including applications described later which alert staff rapidly enough to prevent baby theft /
patient wandering without hampering regular routine hospital workflow activity. In addition this application may be used to feed other activities such as Clinician delivery of patient-specific EMR
data when collocated with patient or may be used to monitor track patient location (e.g.
between departments) as an aid to inter-department transfers.

Key attributes of this application are: -a) The location system must track the location of multiple patients precisely and accurately enough, and with a low enough latency, to allow tracking and finding patients as they are moved between areas, zones or departments and to allow patient/clinician or patient/equipment association as required by client higher level services. Hence this application is required to meet a set of requirements for accuracy (location coordinates, identity) at an adequate time, space resolution, which are set by the client applications b) If this application is integrated with and used by emergency services such as those described later in this document, this application must provide adequate temporal-spatial resolution and accuracy, as well as adequate dependability to respond to those needs too.

c) Security - Patient ID, location can only be disclosed within appropriate circumstances - this is likely to be established and managed by client services d) Dependability - this application must provide location data and patient primitive identifier information at the right quality and when it is needed for use in client services.

Hence the value of this solution is to securely, dependably and with adequate precision, accuracy and latency, collect knowledge of patient location and associated identification primitives to meet the needs of higher level services which themselves enable clinical process controls, clinician-patient associative services and various emergency services as well as patient flow controls to prevent inadvertently "stranded" patients.
Clinician-Nortel Confidential 150 of 226 patient associative services permit more efficient Point of Care capabilities, and allow the pre-fetching of relevant data based on the specific combination of clinician, and patient, as well as more advanced context-aware and situation-aware capabilities enabled by some of the more advanced supported services. This service also can support services which provide more targeted communications (e.g. to security), leading to less disturbance to the general hospital population.

The inputs, outputs and functions for this service at both a basic (support to other services only) and more sophisticated (stand alone utility) variant are given inError!
Reference source not found.

a) Basic location service for input to other services Inputs Outputs Environment Functions = Location vector primitives from location Patient location subsystem (clinician) Processing of raw data to = Patient location = ID primitives from determine patient location, location subsystem vector (clinician) b) Rich stand-alone location service Inputs Outputs Functions Facility information = Hospital map and Patient location and usage allocation context tracking = Patient location and Context - Processing of raw data to mapping to functional = Patient ID's area of facility = Associated clinician ID determine patient location, = Location context input = Each parties terminal vector to other applications, type and connectivity , - Establish patient zone presence induding context Environment history = Location vector I as input to patient context primitives (patient) I~ - Establishing history of location J - Validating patient is at location Figure 14-2 Patient tracking and/or monitoring (R2) The primary ECAS contributors and enablers are: -a) Patient location tracking from the location component of the Environment-Aware aspect of ECAS provides input to location-sensitive services, assists in providing context-aware capabilities, which include physical world location, both by a basic X,Y,Z coordinate grid and by zone.

b) Location-based context awareness leads to better context-interpreted responses which in turn enables more effective, speedier, convenient clinician support services and higher clinical productivity with lower clinical error rates Nortel Confidential 151 of 226 c) Patients don't silently get "lost" between departments or by wandering off or by being abducted d) This service is a key input into an infant physical security service, which would prevent undetected infant abductions Key environmental parameters that ECAS has to discriminate for this service are: -a) Patient location b) Patient identity primitive associated with that location Key Context parameters a) None for a basic location service - context is supplied by higher level services supported by this service (this is a basic patient-tracking service) - this is shown in option a) of Figure 14-2 b) Alternatively a more rich set of capabilities could be provided. This is shown in option b) of Figure 14-2. The basic service supporting others as shown in option a) will be assumed here.

14.3 Equipment Tracking, Location And Condition The objective of this application is to provide tracking of clinical and portable terminal equipment location, environment, and condition as an input to computing equipment situation, and tracking equipment for inventory, theft protection purposes as well as to support unobtrusive workflow integrated, workflow supporting client applications The key attributes of this application are: -a) Continuous and widespread coverage throughout hospital allowing the location, tracking and primitive identification of equipment for various purposes b) Provides a location and implied context input to automating configuration optimization for multiple services, both in and beyond communications c) Provides a basis for several other services due to the ability to track the equipment location, as well as optionally providing location of people, equipment, etc.
near the equipment (in conjunction with other services).

d) Provides the basic location and identity primitive information to allow equipment to be located when needed, equipment and terminals to be tracked for inventory, service delivery and authentication purposes and to prevent equipment and terminal (especially hand-held terminal) loss and/or theft Nortel Confidential 152 of 226 e) Must meet specific latency requirements driven by client services such as:-a. Locating equipment when needed for emergency medical purposes b. Preventing theft during theft attempt, c. Must provide location tracking component accurately enough and with low enough latency so as to be usable by other client applications (e.g. as a component of PoC) f) Security - This application should be able to confirm the identity of tracked equipment and report location and identity only to authorized users of this information - otherwise may become a tool for theft g) Dependability - Some applications dependent upon this application will place significant demands on dependability - e.g. locating crash cart or associating an equipment with a patient or clinician during a medical procedure h) Precision and accuracy - this will vary due to the different demands of various client applications but clinically associative applications will tend to place the most stringent demands on precision, accuracy and dependability simultaneously Hence the value of this solution is that equipment can rapidly be located within the building reducing lost equipment levels, allowing better utilization and reducing the need for capital equipment expenditure. Furthermore equipment can be automatically logged out to authorized exporters when it leaves the building. Theft prevention allows cost savings, services using "thievable" items to be introduced (e.g. WLAN PoC
using hand-held terminals) The inputs, outputs and functions for this service at both a basic (support to other services only) and more sophisticated (stand alone utility) variant are given in Figure Nortel Confidential 153 of 226 a) Basic location service for input to other services Inputs Outputs Functions Equipment location Environment Processing of raw data to = Equipment location vector ~ --- - I= Equipment location primitives determine equipment location, = Equipment ID primitives vector b) Rich stand-alone location service Inputs _ ..........................................................~
Facility information Outputs ~ FunctionS
= Hospital map, zones and usage allocation Equipment location and = Equipment utilization history Context context tracking Equipment location and = Equipment ID's - Processing of raw data to ~= mapping to functional area of = Zone boundaries of permitted determine equipment location, facility equipment movement or use = Location context input to = Equipment utilization primitives ; vector other applications, including Environment Establish equipment zone ~ context history = Equipment location vector presence = Flagging of equipment exiting, outside approved zones primitives Establish history of location = Equipment condition, environment and utilization Determine equipment condition, (sensors) J usage level, etc.

Figure 14-3 Equipment tracking, location, condition (R3) The primary ECAS contributors and enablers are: -a) The equipment location tracking capability of ECAS provides input to location-sensitive services, and optionally assists in providing context-aware capabilities, which include physical world location, both to grid and by zone. This aids rapid equipment location, prevention of theft and inventory control capabilities.

b) The location-based context awareness which is enabled by this allows for better context-interpreted responses. This in turn allows more effective, speedier, convenient consultation sessions leading to higher clinical productivity and lower clinical error rates Key environmental parameters that ECAS has to discriminate for this service are: -a) Equipment location b) Equipment identity primitive associated with that location c) For advanced equipment location, not covered here, there can be additional factors (e.g. various physical environments (sensors - equipment)) - here it is assumed that the equipment location service is a basic one and advanced services are added by client services Nortel Confidential 154 of 226 Key Context parameters a) None for a basic location service - context is supplied by higher level services supported by this service (a basic equipment-tracking service will be assumed here) b) Alternatively a more rich set of capabilities could be provided resulting in various context contents - the basic service supporting others will be assumed here.
For an advanced stand-alone equipment location and monitoring service this would include equipment type, identity, location, environment, authorized location and environmental limits, identity and proximity of associated authenticated clinicians or "owner", proximity of proscribed zones, equipment trajectory relative to proscribed zones, location and identity of security staff, hospital equipment export policies, other authorized exporter identities and locations 14.4 Equipment/Clinician Or Equipment/Patient Association The objective of this application is to provide an ongoing and real time indication of the relative locations of clinicians, patients and equipment so as to allow the determination of which clinicians, patients and equipment (medical equipment or Clinical IT
terminal devices) are physically close enough to each other that they satisfy defined "association by proximity" requirements. This information can be used to associate clinicians with patients, clinicians with equipment or patients with equipment in clinical applications using ECAS.

The key attributes of this application are: -a) Continuous and widespread use throughout hospital in providing association by proximity information to Clinician support services, clinician communications and information support services b) Provides a relative location tracking capability at sufficient precision and accuracy to satisfy the needs of higher level clinical services that are clients of this application as well as computing an implied context aspect (meeting of dynamic proximity conditions such as to meet "association" criteria) allowing the automation of configuration optimization for multiple services, both in and beyond communications c) Lack of association of equipment with clinicians or support staff may indicate unauthorized usage or, if equipment movement is detected, theft or misappropriation d) Low latency is important for some client applications, especially theft discrimination and as inputs to some clinical workflows or workflow stages, since otherwise the human interface and system response would be degraded. This Nortel Confidential 155 of 226 application must meet the latency demands of client services, some of which have real-time interactions with clinicians which require this application to provide adequate time discrimination that service reconfiguration is "immediate" in human time scales, as well as other services which are based on the location tracking and association and which also have to see adequate responses-to-need.

e) Must positively identify associated parties -misidentifying non-clinicians as clinicians or misidentifying clinician identities can lead to HIPAA violations f) Dependability - this application must provide consistently accurate results for the identity and proximity of associated parties Hence the value of this solution is the ability to provide real time correlated locations and detected proximity situations meeting specified association criteria to higher level clinical services for the purposes of allowing these services to be more anticipatory, user friendly and efficient. This includes selective pre-fetching of data, discriminating between authorized and unauthorized usage, personal profile or customization downloads, services reconfiguration and many other capabilities detailed in the higher level services. It is anticipated that location/situation optimized services will improve user satisfaction, user proclivity to use the solutions, user ability to use system efficiently and effectively and protect the users and the facility from data theft, equipment theft, as well as inappropriate access to clinical data.

a) Basic association service for input to other services Inputs Outputs Functions Environment Clinician location, vector, ID primitives Equipment / clinician / patient Clinician/patient, Patient location, vector, ID primitives association clinician/equipment and Equipment IocaGon, vector, ID primitives ,r f s{ patienUequipment Any proximity detector outputs vvitn Processing of raw location data proximity event characteristics parametric data ( range, ID of parties) to determine proximity conditions b) Rich stand-alone association service Inputs _ .....................................................................
Facility/clinical information Functions Hospital grid map, zones and usage allocation Outputs Equipment utilizatlon history Equipment / clinician / patient Clinician ID's, roles, profile ) Context association Equipment ID's Processing of raw location data Zone boundaries of permitted equipment to determine proximity Clinician/patient, movement or use clinician/equipment and condltlons atienUe ui ment Equipment utilization primitives P q P
= Clinician terminal type and connectivity ', - Establish , track role of clinician proximity event = charaderistics Clinician role by zone with patient by zone inference ~K f Environment Proximity event location blis h history = Clinician location, vector, ID primitives Esta of proximity and zone, inferred Patient location, vector, ID primitives events for each proximity possible range of Equipment location, vector, ID primitives combination ? _ situations Any proximity detector outputs with parametnc data ( range, ID of parties - Determine equipment Equipment condition, environment and authentication utilization (sensors) Figure 14-4 Equipment / clinician / patient association (R4) Nortel Confidential 156 of 226 The inputs, outputs and functions for this service at both a basic (support to other services only) and more sophisticated (stand alone utility) variant are given in Figure The primary ECAS contributors and enablers are: -a) Equipment/clinician/patient proximity-based association can provide input into multiple services for clinicians b) Clinician/patient association can accelerate and simplify the PoC process by pre-fetching and organizing clinical data based upon the patient's identity, clinicians authorization level and may simplify authentication, by allowing a clinician to remain authenticated all the time a terminal is within their personal zone c) Clinician/equipment association can be used to log equipment to a particular clinician, should they exit a department, zone or building together - lack of such association represents unauthorized movement or theft Key environmental parameters that ECAS has to discriminate for this service are: -a) Relative location or proximity (clinicians) b) Relative location or proximity (patients) c) Relative location or proximity (equipment) d) Identity primitives for the above Key Context parameters Location zone map of facility, proximity and association policy inputs, possible go and no go zones for equipment and/or patients 14.5 Clinician Point Of Care Communications The objective of this application is to provide unobtrusive and workflow integrated, workflow supporting communication of data to/from the PoC in a secure, easy to use and dependable manner, such that the workflows surrounding point of care sessions can beneficially evolved to become more efficient, effective, safe and mutually beneficial for the clinicians and patients by the application of information technology inside the clinical workflow The key attributes of this application are: -a) Widespread use throughout hospital in supporting Clinician examination, diagnosis and treatment of patients including fetching requested information and capturing and disseminating generated information, decisions and orders Nortel Confidential 157 of 226 b) Supports Point of Care decision-making both with the patient and away from the patient by providing access to information, ability to capture information and consult with colleagues c) Time critical - During patient encounters clinicians do not want to be waiting on system responses or dealing with a slow or variable system response.
Examination and diagnosis sessions often require several decisions in sequence so decision validation on each decision needs to be real-time d) Security - HIPAA requirements apply. System must only respond to lawful requests for action from authenticated clinicians, operating within allowable context. Patient identifiable clinical data must not be shared with unauthorized or unauthenticated third parties.

e) Dependability - If successful this approach will be deeply integrated into clinicians' workflow practices and decision-making processes so must be extremely dependable in all key attributes. This means meeting Clinical Grade, both for the conventional IT infrastructure aspects and for the add-on ECAS
components.

Hence the value of this solution is that it can provide a much greater capability, effectiveness and ease-of-use to a suite of high usage, widely used, clinician support tools specifically targeted at increasing clinical effectiveness, efficiency and reducing errors.
The clinicians' ability to exploit comprehensive data access, input and interaction at PoC
simplifies and speeds up the clinical workflow, while allowing for more informed more validated decisions which can be more accurately and rapidly captured and disseminated - this is what achieves the increased efficiency, effectiveness and saves lives/reduces medical errors.. Use of ECAS with PoC tools also enhances convenience and security features which improve user satisfaction and the user ability to use system while improving the protection of the user and facility from inappropriate access to sensitive data. The inputs, outputs and functions for this service are given in Figure Inputs Functions Outputs Clinical information = EHR, EMR, EPR access PoC encounter = Test results and reports ~~ - Access to, entry of Clinical information = Decisions and orders i patient-identifiable Decision validation I = EHR, EMR, EPR input clinical data = Test results input Consultation Context - Decision capture and ~= Decisions and orders = Clinical ID and authorizations access to validation tools = Consultation = Authentication status Access to clinical = Clinical role :-Authentication and comms = Patient ID ;_ - collaboration (R6) tools = Clinician identity and = Clinician/patient, Clinician/ Order reception and authentication primitives equipment associations (R4) placement ~= Patient identity/identity = Location of patient, location of PoCI confirmation = Terminal t e and connectivit ~ - Clinician authentication Yp Y = Equipment Identity/
Environment and patient-association, identity confirmation = Location (clinician, patient, terminal) equipment association (RI-3) Figure 14-5 Clinician Point of Care Communications (R5) Nortel Confidential 158 of 226 The primary ECAS contributors and enablers are: -a) Location awareness, proximity detection and establishing associations allows more context to be provided to the clinical applications, based on clinician-patient physical proximity, PoC location, etc. This allows the most relevant data to be pre-fetched or to be placed at the head of a queue or list, can automate various features and can reduce clinician workload associated with accessing and using the Clinical IT system b) Context awareness enables better context-interpreted responses by higher level clinical applications which in turn provides for more effective, speedier, convenient PoC sessions c) Context-based Clinician role or situation, clinician-patient association, Clinician-equipment and clinician-terminal association, identity of clinician, terminal, patient, equipment, authentication status inputs based on location discrimination enables advanced features in multiple PoC user scenarios Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (PoC event) b) Location (first party/ session origination clinician) c) Location (patient) d) Location (equipment) e) Location (terminal) f) Ongoing dynamic proximities and associations based upon proximity definitions Key Context parameters a) Facility mappings of locations to zones, functions within zones, b) Clinician authorization and authentication, c) Clinician-patient mapping list, d) Clinician duty roster, e) Patient record access privileges, f) Patient location, patient status, g) Information connectivity system parameters, h) Information connectivity terminal properties, i) Location and use of other nearby terminals + their properties 14.6 Clinical Collaboration The objective of this application is to provide unobtrusive and workflow integrated, workflow supporting communication of data between clinicians in a secure, easy to use manner Nortel Confidential 159 of 226 The key attributes of this application are: -a) Widespread use throughout hospital in supporting Clinician to Clinician dialog, instructions and consultation b) Supports Point of Care decision-making both with the patient and away from the patient (aka Point of Decision) c) May occur between collocated clinicians or physically separated clinicians, including clinicians in public areas d) Low latency - Clinicians will not wait for system responses or deal with a slow or variable system response e) Security - HIPAA requirements apply to release of confidential patient information - the consultations must be secure which requires that both/all parties be authenticated before any support files delivered and that the communications medium and delivery method to the end user be appropriate for each end-user location - e.g. no use of "hands-free" speaker systems in public places Hence the value of this solution is that it provides a high usage, widely used, clinician support tool to improve clinician collaboration, consultation and order placement thereby improving clinical efficiency. The ability to provide real time on-demand clinician to clinician dialog increases efficiency, effectiveness and saves lives/reduces medical errors Convenience and security features improve user satisfaction, user proclivity to use, user ability to use system and protect user and facility from data theft, equipment theft, inappropriate access to data The inputs, outputs and functions for this service are given in Figure 14-6 Inputs Outputs Clinical information = EHR, EMR, EPR access = Test results and reports Functions = Decisions and orders i = Decision validation Clinical collaboration Consultation j or consultation Clinical information Context = Clinical ID's & authentication for participants ACCess to, entry of = EHR, EMR, EPR input = Authorization statuses - context patient-identifiable = Test results input =Clinical roles clinical data = Decisions and orders =Patient ID Order reception and = Consultation =Clinician/patient mappings =Patient situation, location placement = Location of patient, location of CC parties Clinician authentication = Each parties terminal type and connectivity and patient-association Environment = Location (clinicians, patient, terminal) Figure 14-6 Clinical Collaboration (R6) Nortel Confidential 160 of 226 The primary ECAS contributors and enablers are: -a) Location awareness allows for more context-input into the collaboration tools, based on clinician- consultation member location, etc.

b) Context awareness enables context-interpreted responses leading to more effective, speedier, convenient consultation sessions which in turn leads to higher clinical productivity and lower clinical error rates c) Clinician role, identity, authentication status input, location-based activity, Clinician/patient mapping of roles for each party d) PoC location, proximity of patient, clinician if appropriate e) Terminal type and performance, network connectivity path Key environmental parameters that ECAS has to discriminate for this service are: -a) Locations (collaboration event) b) Location (first party/ session origination clinician) c) Location (other clinicians) d) Location (patient - if relevant) e) Location (equipment) f) Location (terminals - all parties) g) Ongoing dynamic proximities and associations based upon proximity definitions Key Context parameters a) Clinician authorization and authentication for both/all parties, b) Clinician roles, permissions c) Clinician-patient associations (location, and "is this clinician responsible for this patient?") d) Location of each party, clinician patient mapping list, e) Clinician duty roster, patient record access privileges, f) Patient status, emergency/non-emergency medical status, g) Each parties data delivery system, h) Data delivery terminal properties, i) Location and use of other nearby terminals + their properties 14.7 Drug Safety, Security And Environment The multiple objectives of this suite of application is to provide a validation that drugs are safely securely stored and handled so that theft or loss is avoided, drugs are not Nortel Confidential 161 of 226 damaged or contaminated and that, when it is time to administer the drugs to patients, that the correct high quality product is properly administered, that drug inventory taking and (with use of suitable RFID) sequencing is performed to avoid "stale-dating", the prevention of drug loss due to theft, misplacement or damage due to environmental overstress. Prevention of drug loss due to theft, misplacement or damage due to environmental overstress must be complemented by allowing for legitimate movement around the hospital, as well as legitimate authorized clinician access. In particular there needs to be continuous monitoring of the location of expensive, limited access medications and drugs and narcotic drugs which are high risk targets for crime, as well as environmental monitoring of environmentally sensitive drugs.

The key attributes of this application are: -a) Low latency -a. Drug administration support must be rapid since the clinician will be awaiting confirmations at key steps of the process for each patient drug administration b. Drug misplacement needs to be corrected before third party finds drugs, c. Environmental stress needs to be detected and corrected before drug is damaged (E.G. drug cart location and thermal/sun loading environment and other environmental parameters tracked) d. Drug theft needs to be detected and stopped before theft is completed (E.G.
Thief stopped before exiting pharmacy or exiting building) b) Security - Drug whereabouts and inventory data must be protected, unauthorized third party access not allowed, or must yield useless data, while authorized access must yield accurate data, including at the scanning primitives level c) Dependability - Drug mis-identification can lead to ADR's so type identification must be accurate or supported by human visual confirmation, itself an error-prone process. Inventory requires accurate counting and type identification d) Different drugs have different environmental limits and shelf lives so accurate drug identification important to maintaining environmental safety and to minimize expired life product Hence the value of this solution is that material and inventory tracking and protection can protect the drug supply while controlled and validated drug administration to patients in a closed loop system has been projected (Ref XXX) to massively reduce ADE's, and to save lives. It allows for the prevention or at least minimization of loss of drugs due to theft, misplacement, damage as well as a real time ability to locate and track drug carts, major drugs in hospital as well as an ability to monitor and potentially control access to restricted access drugs Nortel Confrdential 162 of 226 The inputs, outputs and functions for this service are given in Figure 14-7 Inputs R
Facility information Hospital grid map, zones and usage allocation Funct ons Outputs including Pharmacy coordinates, zone, Drug cart ---routes, route history, drug storage sites j Drug safety, security and Clinical environment Clinician ID, Drug ID, quantity (by RFID scan, manual entry), Pharmacist ID, Patient ID - Tracking whereabouts of r' = Drug location, inventory Context l drugs through the chain from ~= Alerts for misplaced drugs, Clinician role, authentication, authorizations ~ unauthorized drug movement = Clinician/drug/patient association at administration incoming to pharmacy to = Alerts for drugs approaching Patient drug history, drug regimen --r patient administration 'stale date"/support to Zone boundaries of permitted movement or use - Protecting drugs from properly sequence drug Drug environmental safety (from dnig type and usage sensed drug environment) misplacement, theft or being = Alerts for drugs exposed to Environment exposed to harmful lim@ environmental conditions Drug cart ID and location environmental conditions = Support for validated safe Drug ID (RFID) on cart or before administering drug administration to Drug location (by RFID reader location) - Enabling drug inventory Packaged drug quantities in stores, on cart (RFID) patients Sensors - drug cart and drug store environment -;' activities possible individual dnxg package environment- by - Supporfing safe validated RFID sensors administration procedures Figure 14-7 Drug safety, security and environment (R7) The primary ECAS contributors and enablers are: -a) Providing a real-time view of the whereabouts and contents of the hospital drug inventory by tracking hierarchical packaging at box, container, drug cart level and potentially at the prepared patient dose level (for drug-patient administration purposes) b) Detecting, alerting unsafe conditions and practices c) Supporting safe validated drug administration d) Alerting potential drug misplacement, drug theft situations Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (drug cart, major drug containers but not every single pill) b) Sensor (thermal, possibly light/UV, possibly humidity/water) at the phartnacy, pharmacy storage shelf/closet/refrigerator/freezer level and on the drug carts within the rest of the hospital c) Identity via RFID scanner, itself being locatable d) Patient and administrator location, identity primitives Key Context parameters a) Drug type, value, b) Access restrictions, Nortel Confidential 163 of 226 c) Required drug environment, d) Actual drug environment, e) Clinician drug rights and privileges, f) Drug location, g) Cart location, h) Proximate clinicians i) Patient drug administration schedule and history 14.8 Various Applications In Support Areas It is anticipated that both clinical and non-clinical services that can benefit from ECAS
will be found in various other areas of the hospital not yet examined. These include: -a) Radiology/PACS, b) Cardiology, c) Nuclear Medicine, d) Pathology, e) Other test labs & functions f) Other imaging g) Emergency (microcosm of entire hospital - often on steroids) These will be considered in a later phase of work 14.9 Routine equipment and terminal calibration, maintenance and verification Besides the clinically focused applications and support applications to those applications it is anticipated that ECAS can be applied to massively simplify and enhance the routine maintenance and tracking of clinical equipment and hand-held terminals. This will be explored in a later stage of work.

Nortel Confidential 164 of 226 15 Appendix - Basic Functions and Requirements For Selected Major Emergency Application Areas This appendix will explore multiple "emergency" applications across the spectrum from "independent of clinical practice" to "clinical practice-enabling". They will be presented from a perspective of their communications functionality. This section includes a suite of emergencies for which most hospitals have formalized emergency plans and which are identified by "Codes" as well as some emergency situations that do not appear to have formal codes.

15.1 Emergency (E) "Code" - Various Emergency Codes Ohio Emergency Codes Code Event Response ECAS implications Red Fire ParGaUtotal evacuaUon, fire location Find location of, confirm fire, toxic products spread (nature, coverage) and fighting Adam Missing infant "Lock down" building, seek child Locate/track location tag on missing infant or child, raise alarm before infarrt or child or child and/or abductor enters hazardous area or is removed from building, locate all non-employees, video and sensor searches of building, auto-review of exit door video, sensor logs Black Bomb/bomb Partial/total evacuation, threat Find location of, and existence of bomb (sensors), identify placement agents from threat assessment, bomb location historical video, archived sensor data.
Gray Severe Monitor building for damage, move Building condition monitoring (sensors, video), confirmation of employee location weather staff and patients as appropriate to (especially for evacuated areas) threat, damage, prepare for incoming casualties Orange Hazardous Identify material threat, contain, Sensors to detect, locate and track release eady, track spread, track residual material neutralize and clean up, treat contamination after clean up, identify exposed personnel and degree of exposure, spill/release exposed people, equipment track exposed personnel contacts, especially for biological agent releases Blue Medical Identify location of patient, notify all Establish location and identity of patient, location, idenBty of alarm instfgator, location emergency- "proximate" clinicians, assemble and current activities of prospective emergency response team members, form team adult emergency treatment team, and notify team members of event location, idenfity, deliver pertinent dinical equipment at site information Pink Medical As "Blue" As "Blue" but first seeking pediatric expertise emergency-pediatric Yellow Disaster Assess nature and scope of disaster, Notify all pertinent and available personnel, form trauma, triage teams based upon (extemal) prepare accordingly. Clear ER of all skills, shifts. Catalog loca6on, current status of all ER and non-ER emergency-non-essential activities, patients supporting equipment. As soon as nature of disaster, identity of victims is available assemble clinical information pertinent to disaster responses, victim records (if any) Violet Violent or Restrain, calm patient and stabilize Detection of patient movement or actions indicative of this state? Identify and notify combative patient state proximate security personnel and any other response teams required patient Silver Armed person Evacuate area, contain situation with Detection of weapon at entry doors (sensors), track suspects before, after security or hostage local security, notify law enforcement involvement, identify and notify proximate security personnel and any other response situation teams required Brown Missing adult Semi "Lock down" building, seek lost Locate/track location tag on patient, raise alarm before patient exits building, video patient patient and sensor searches of building, auto-review of exit door video, sensor logs Underlined code = deak with in depth in this document Table 15-1 Various emergency codes and ECAS implications Hospitals have to be ready for multiple different emergencies and types of emergencies both clinical and non-clinical in nature. As mentioned earlier part of their response is to "codify" the nature of any given emergencies, especially the more common or more serious ones, so that the shorthand of the Code name can be used to activate a hopefully well drilled response appropriate to that emergency. There are many emergency types and many ways an ECAS-like capability can assist in times of emergency. Some of these Nortel Confidential 165 of 226 are captured in Table 15-1 Various emergency codes and ECAS implications. The Codes with underlined titles in this table will be explored further in the following sections 15.2 Code Blue/Pink - Emergency Cardiac/Respiratory Event -Adult/Pediatric The objective of this application is to provide appropriate immediate clinical support, by building a "code" clinical response team rapidly @ event site, by immediate notification to proximate appropriately skilled clinicians, and to other required code team/resuscitation team members for purpose of assessing, stabilizing and saving patient, and to trigger the availability of appropriate, fully functional equipment at the code site.
Furthermore the solution should advise clinicians en route to the scene as to the circumstances at the scene by one or more of several methods.
The key attributes of this application are: -a) Triggered by an (usually) unexpected life-threatening emergency or an expected emergency of unpredictable timing b) May occur without warning at any patient-populated (or staff-populated or visitor populated) area or location within or outside of the facility c) Controlled low latency - This is a real time emergency situation - "seconds matter" in re-establishing oxygen flow to the brain. Hence identifying the location of event, possibly the nature of event, identifying proximate clinicians and nearest resuscitation "code" team members rapidly and accurately and giving them accurate instructions is vital d) Security - Whilst a secondary consideration during the emergency event no inappropriate information should be broadcast and release of information to normally ineligible clinicians should be logged under a "battle-switch"
scenario e) Dependability - The solution must accurately and consistently facilitate the rapid notification of nearby clinicians as well as the fast formation of a qualified "code"
resuscitation response team, based on available "code" qualified clinicians nearest to the event location without error in either the location or the team-member choice and notification. This requires accurately identifying the patient location and identity at the event site, as well as the best set of responders or close to the best set of responders every time.

Hence the value of this solution is that it facilitates a very rapid formation of an appropriate clinical team that is proximate to the triggering event. The quicker team formation saves time before resuscitation can begin, which may save lives.
Calling the nearest available appropriately skilled clinicians saves time whilst minimizing disruption on the rest of the facility. Calling only available clinicians in the first instance reduces workflow disruption. Calling appropriately skilled clinicians optimizes team skill mix.
Nortel Confidential 166 of 226 Targeted communications only to chosen team members means less disturbance to the general hospital population.

Once the team assembles at the Code Blue site the Code Blue solution effectively becomes a very pressured, mission critical version of a Point of care encounter, with a high level of local Clinician collaboration.

The inputs, outputs and functions for this service are given in Figure 15-1 Inputs Outputs Facility Information Hospital grid, zone map, table of travel times i Functions Clinician duty roster Current Ginicians tasks/availability Code alarm input location COd@ BIU6 2V@nt Code blue team structure policy Location of code blue event, Clinical information identification of code blue victim Nature of first responders observations Identification of code source clinician EHR, EMR, EPR information Location of nearby clinicians and their Consultations, decisions and orders notification Context ; Clinical information Clinical ID and authorizations Forming code blue team to policy I= EHR, EMR, EPR input Authentication status ; Skill set x location x availability for )= Decisions and orders Clinical role/skill set/ code" qualifications l .................~ clinicians for further treatment Clinician/patient mapping ! = Consultation Terminal types and connectivity - Notify nearest available clinicians of .
Environment code blue team membership, location Drug requests, etc.
Location - first responder clinician, proximate ,~, - Support code blue response team Ginicians, code team members, patient, all with enhanced access to clinical data, terminals, crash carts resources Patient ID, - Identify, validate condition of Crash Clinician ID (first responder, proximate carts clinicians, members of code team) i ...........
..................................
...............................................................................
.....i ID of crash carts Figure 15-1 Code Blue - emergency cardiac/ respiratory event - adult (E1) The primary ECAS contributors / enablers during the team formation phase are: -a) Location-aware team formation means the team members can arrive on-site quicker - this may be important b) Real time forming of nearest appropriate clinicians based on the context of the clinicians' skills and emergency training, location and availability (e.g. not in the middle of heart surgery) forms the strongest team possible more rapidly available at Code site and with minimized disruption to the rest of the facility c) Rapid identification of clinicians able to help d) Nearby general clinical population e) Builds skilled Code team to policy needs rapidly f) Identification, location and status of nearby "crash carts"

Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (event) b) Location (clinicians) c) Location (equipment) Nortel Confidential 167 of 226 d) Identification of clinicians, patient Key Context parameters a) Per-physician location relative to event location b) Clinician current activity c) Patient identity and history, d) Nature of code event (blue in this case), e) Per-clinician skill, f) Clinician duty roster, & location, g) Skill requirement match to event type 15.3 Code Adam - Missing Infant Or Child The objective of this application is to track the whereabouts of newborn/infant/child patients and alert staff rapidly enough to prevent abduction while allowing regular routine hospital workflow activity. As such the intent is to avoid a Code Adam - an abducted or lost minor - before it completes and the minor exits the building or reaches an inappropriate part of the building. Location tracking aspects may be common with other activities such as Clinician delivery of EMR data when collocated with patient or may be used "stand-alone" for prevention of baby theft.

The key attributes of this application are: -a) Low latency - System must track infant location, mapped to zones and infant proximity to clinicians, authorized patients (mother) rapidly enough that unauthorized infant movement can be alerted before theft takes place b) Accurate location and accurate proximity detection - required to discriminate between a minor exiting the local area unescorted, or with an abductor, versus exiting with a clinician or with a family member - this would require visitors who are family members to wear some form of visitors pass with a location capability or RFID tag built in.

c) Accurate identification of minor identity primitives, clinician identity primitives and badged visitor identity primitives d) Dependability - the solution must not allow the "silent" abduction or loss of patients who are trackable minors, neither may it create many false alarms -setting a high standard for the performance of the context analysis stage Hence the value of this solution is that the abduction or loss of minors within the facility can be prevented or massively reduced, and when such an event does occur the use of the location solution will allow a very rapid determination of whether the minor is still in the facility and whether the minor's movements match an abduction in progress or just a Nortel Confidential 168 of 226 wandering child. Preventing baby theft saves much angst, bad publicity, lawsuits.
Tracking newborn infants from birth also allows for detection and prevention of "swapped infants" - a major, if rarely activated, additional side benefit.
Calling nearest security personnel to the suspected abduction event saves time and targeted communications to just those security people results in less disruption the general hospital population The inputs, outputs and functions for this service are given in Figure 15-2 tn~uts Functions R
Facility/clinical in ormation ~ Outputs Hospital grid map, no-go zones Infant abduction response Clinician ID's, roles, profile Processing of raw location data to Infant ID and associated approved determine infant location and patient (usually mother) ID
Alert response as function of nature of proximity conditions Tracking of infant location violation - Establish , infant location against Context allowed zones, conditional allowed and associations over stay Zone boundaries of permitted infant zones and exdusion zones in hospital =
movement as function of proximity Flagged alerts for Establish history of proximity ~- ----.
Clinician terrninal type and connectivity events for each proximity j violations of policy on Clinician role by zone infant location zones i proximities = Security response as function of violation, combination versus Environment - Validate infant associated with = Validation of correct Clinician IocaGon vector primitives correct adult infant/patient association Infant location vector primitives - Provide escalating flags based on Authorized patient location vector primitives '- nature of violations in a rapid Any proximity detector outputs with parametric manner data ( range, ID of parties detected) %

Figure 15-2 "Code Adam"- Newborn/infant abduction response (E2) The primary ECAS contributors and enablers are: -a) Real time monitoring and tracking of the location of infant or minor patients, comparison against the allowable zones for that patient under the current context and analysis for threat conditions based on infant location, vector against approved, conditional, no-go zones. Note that a minor patient with no proximate clinician will have a tightly defined zone where they are supposed to be, but that a minor patient in association with a clinician (proximity criteria are met and remain met) may travel to different parts of the facility, where other zones may exist where the minor patient can be located without proximate associated clinicians.

b) Threat conditions versus location are adapted by proximity of authenticated authorized clinicians (who may take the infant into zones that could otherwise not be visited) and by authenticated authorized specific patient (usually mother) c) Rapid alerting to nearby clinicians and / or security staff dependent upon detected threat.

d) An infant or minor heading to exterior door with no clinician or approved patient in proximity should trigger the highest possible security response Nortel Confidential 169 of 226 e) If the infant and mother or infant plus tagged family member cross an internal threshold from "OK" zone to "clinician accompanied" zone this should cause a nearby clinician to steer mother back to where she and her infant should be but not to trigger a security event..

Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (infant) b) Location (clinicians) c) Location (approved patient/visitor) d) Location (security personnel) e) Identity primitives for all of the above Key Context parameters a) Subject dynamic location, vector b) Hospital zones and permissions c) Location of proscribed zones, building and/or area entrances and exits d) Location of hazardous equipment e) Parameters associated with Infant ID
f) Associated clinician ID's g) Associated clinician duty shifts h) Associated approved patient ID (e.g. mother of newborn) i) Associated visitor ID (e.g. father) j) Associated rights of h), i) 15.4 Code Brown - Wandering Patient Protection The objective of this application is to track the whereabouts of specific patients who are prone to wander and to alert staff rapidly enough to prevent the patient wandering into proscribed areas while allowing regular routine hospital workflow activity.
Location tracking aspects may be common with other activities or may be used "stand-alone".
The key attributes of this application are: -a) Low latency - System must track patient location and proximity to clinicians, map this to zones rapidly and accurately enough that unauthorized patient movement (wandering) can be alerted before risk of injury or disturbance takes place b) Security - Lost/ wandering patient information should only go to those who "need to know" - certain clinicians and sometimes security c) Dependability - To avoid spurious alerts are the solution should (to a high degree of confidence) a. flag a lone patient crossing into a no-go zone Nortel Confidential 170 of 226 b. should not flag a patient who is in an OK zone near to a no-go zone but not vectored towards the no-go zone c. should not flag a patient who is in a conditional go-zone in the company of a clinician who has sufficient permissions to take the patient there Hence the value of this solution is that preventing patient wandering reduces patient loss/misplacement, reduces disruption to workflow due to need to divert resources to finding the patient and suspending treatments until patient is found, saves much angst, bad publicity, lawsuits. Preventing patients approaching unreasonable hazards (in context of patient faculties) reduces risk of patient accidental injury. Selectively notifying the nearest security personnel to event saves time and targeted communications to the appropriate clinical personnel and security personnel causes less disturbance to general hospital population The inputs, outputs and functions for this service are given in Figure 15-3 Inputs Functions Wandering patient protection Outputs Facility/clinical information Hospital grid map, no-go zones Processing of raw location data to Clinician ID's, roles, profile determine patient location and Patient ID and associated wandering >-+ proximity conditions history Alert esponse as function of nature of I - Establish , patient location against ( = Tracking of patient violation allowed zones, conditional allowed location and associations Context zones and exdusion zones over stay in hospital Zone boundaries of permitted patient I.._ - Establish history of proximity ~-~-' = Flagged alerts for movement as function of proximity elements,,~, events for each proximity violations of policy on Clinician terminal type and connectivity combination J patient location zones Clinician role by zone = Security response as function of violation Provide escalating flags based on versus proximities Environment -; nature of violations in a rapid Clinician location vector primitives manner Patient location vector primitives Any proximity detector outputs with parametric data ( range, ID of parties detected) J

Figure 15-3 Code Brown - Wandering patient protection (E3) The primary ECAS contributors and enablers are: -a) Real time monitoring of patient location and analysis for threat conditions based on patient location, vector against approved, conditional go, no-go zones b) Threat conditions versus location are adapted by proximity of authenticated authorized clinicians (who may take the patient into zones that could otherwise not be visited) c) Rapid alerting to nearby clinicians and / or security staff dependent upon detected threat.
d) Patient heading to exterior door with no clinician in tracking proximity can trigger targeted highest possible security response Key environmental parameters that ECAS has to discriminate for this service are: -Nortel Confidential 171 of 226 a) Location (patient prone to wander) b) Location (clinicians) c) Location (approved visitor) d) Location (security personnel) e) Identity primitives for all of the above Key Context parameters a) Subject dynamic location, vector b) Hospital zones and permissions c) Location of proscribed zones, building and/or area entrances and exits d) Location of hazardous equipment e) Parameters associated with Patient ID
f) Associated clinician ID's g) Associated clinician duty shifts h) Associated visitor ID (e.g. son, daughter) i) Associated rights of h) 15.5 Code Yellow - Disaster Response The objective of this application is to assist in rapidly organizing the hospital to handle a flood of incoming casualties from an external disaster such as a plane crash, earthquake or major terrorist attack. It will help to implement the hospital disaster plan, communicate assignments, and establish teams. It will support the disaster response teams with high quality PoC communications, consultation communications, access to information, order entry in a manner similar to PoC and Clinician collaboration but with different association parameters and increased access to the "battle-switch" which overrides normal security protocols but logs the authorized clinician who activated the request. It will track clinicians and patients in a situation where, with so many patients, it is easy for patients to be "lost". The appropriate transformation of the hospital needs to take place without significantly increasing the risks to existing patients so the current patient and clinician situation has to be taken into account when the disaster response teams are formed. For instance the first teams may be formed by clinicians with appropriate skills who are relatively available, while other teams are formed as clinicians become available and the remaining clinicians are put on a protocol for skeleton staff management of pre-existing patients The key attributes of this application are: -a) This application of ECAS can bring situational awareness, environmental awareness to the process of transforming the entire hospital from a routine operating mode to various levels of disaster-response mode b) Team structures may be pre-planned (as per Code Blue- where everybody understands their role IF they are Code tagged) or formed at the time of the Nortel Confidential 172 of 226 disaster response initiation, based upon skill sets and availability/forced availability but need to be populated based on who is on-duty and available.
This will primarily be handled by ECAS collaborating with a central processing resource and supplying appropriate environment and context data and decisions from which the central resource can modify its disaster response transition by combining this data with an examination of the duty roster, skills list, clinical assignments, the graduated disaster response plan in the HIS and context information as to who is it what situation - for instance it would be inappropriate to pull a surgeon from an open-heart operation in progress to join a disaster response team until the surgery is in "close up" and he/she is no longer needed.
That same surgeon, doing routine bed rounds, can be called immediately c) This is a complex transformation with much processing, to which ECAS can contribute, rather than do, but inputs from ECAS must be low latency - the whole transformation must take 10's of seconds or a few minutes and not longer, so assignees can reach their positions before casualties arrive d) Once the teams are formed and disaster victims start arriving ECAS must enable or support high quality timely PoC-type support and clinical consultation communications support in a very high traffic environment and with modified permissions, associations as derived from the disaster response plan e) Security - Modified security constraints if invoked by hospital policy, must be followed and actions, information-flows tagged for later validation f) Dependability - Both in terms of support to team formation and in providing the PoC/clinician communications features (along with the ECAS capabilities) the network must remain dependable through the heaviest traffic demands placed on it - this means a robustly engineered solution Hence the value of this solution is that the hospital can be more rapidly and effectively prepared and organized for incoming disaster casualties without putting pre-existing patients at increased risk and can more effectively treat and process disaster victims because the best appropriate teams are formed, based on available staff, their skills and current work activities. Once the teams are formed then all the benefits of HCIT-enabled PoC healthcare can be practiced in the emergency situation without additional delays or network "brown-out"

The inputs, outputs and functions for this service are given in Figure 15-4 Nortel Confidential 173 of 226 Facility Information Inputs Functions Outputs R
Hospital grid, zone map Code Yellow-Disaster response Clinician duty roster Part I Preparation = Current dinidans tasks/availability Assessment of scale, nature of disaster -CliEHnicalR, EMR, information EPR input Code alarm input location estimate of incoming casualties = Code blue team structure policy - Fomiing code yellow teams to policy =
Decisions and orders Clinical information - Skill set x location x availability for dinidans for further treatment Nature of first res onders observations Notify dinicians of code yellow team p membership, location Consultation EHR, EMR, EPR information Consultations, decisions and orders Ident'rfy, validate condition of Crash carts .= Drug requests, etc.
= ( Test results and reports Part 2-Initial treatment Decision validation ~ Support code yellow team with enhanced = Triaged patients Context access to dinical data, resources appropriately stabilized for Clinical ID and authorizations - POC data access ongoing treatment in a Authentication status Patient location and ID tracking regular hospital process Clinical role/skill set/"code" qualifications Possible collection of patient monitor data where appropriate Patient ID & Clinidan/patient mapping --- ~ and setting alarm thresholds Terminal types and connedivity Access to, entry of Patient location patient-identifiable = Patient Triage rating dinical data Environment - Order reception and Location - proximate dinicians, code team placement members, patient, all terminals, crash carts Clinician authentication and patient-Patient ID, Clinician IDs (first responder, assodation proximate clinicians, members of code team) ID of crash carts, terminals, equipment Figure 15-4 Code Yellow - Disaster Response (E5) The primary ECAS contributors and enablers are: -a) Hospital preparation - team building, human & equipment resource inventorying, validation of condition, situation and availability b) Communication to teams for purposes of team set up, nature of disaster, roles to be played c) Supporting the Code Yellow teams in incoming patient handling, ID
allocation, triage and initial clinical treatment, ongoing clinical treatment by code teams until patients are beyond help, or are admitted into general hospital process or are discharged Key environmental parameters that ECAS has to discriminate for this service are: -a) Location and proximity - clinicians b) Location and proximity - current hospital patients c) Location and proximity - disaster victim patients d) Location and proximity - equipment e) Location and proximity - terminals f) Sensor- related detection of harmful materials on victims or incoming equipment g) Sensor- related detection of harmful toxins on victims or incoming equipment h) Sensor- related detection of harmful gases on victims or incoming equipment i) Sensor- related detection of harmful biologics on victims or incoming equipment j) Sensor- related detection of harmful radiation on victims or incoming equipment k) Incoming patient condition parameters from Emergency Response team sensors -this will be considered in a later phase of this work Nortel Confidential 174 of 226 Key Context parameters a) nature and scale of disaster event, and required magnitude of disaster response b) Skill requirement match to event type c) Clinician duty roster, d) Per-clinician skill e) Required per-team skills, f) Clinician current activity & location, g) Clinician patient mapping list, h) Current patient load status i) Code Yellow team formation status j) Code Yellow victim patient history access, k) Code Yellow patient record access privileges, 1) clinician authorization and authentication, m) Code Yellow patient location, patient triage status, n) Code Yellow patient - clinician mapping and association o) Information connectivity system parameters, p) Information connectivity terminal properties, q) Location and use of other nearby terminals + their properties 15.6 Code Red - Fire The objective of this application is to place the hospital on emergency response footing in the case that a fire has occurred, to ensure persons are accounted for, to identify the location of the fire and to provide environmental and context input in support of initial steps to contain its impact The key attributes of this application are: -a) Time critical a. Fire must be sensed in its early stages b. Patients and staff potentially / actually in harms way must be identified, alerted and evacuated c. Fire Response personnel at risk must be flagged b) Fire assessment a. Accurate location of seat of the fire and evolving extent needs to be sensed b. Rapid early steps to contain, starve fire can make later fighting easier, minimizes damage c. Spread of smoke, toxic by-products must be tracked d. Nearby objects that represent a hazard in a fire situation must be identified c) Security a. Patient identifiable clinical information not involved/hardly involved Nortel Confidential 175 of 226 b. Physical security of the person and prevention of equipment loss, theft during chaotic time of emergency is an issue to be addressed d) Environment a. Track progress of fire, smoke, byproducts b. Track location, conditions for fire response personnel c. Provide early alert for smoke and fire byproducts approaching unevacuated areas e) Dependability a. Fire location, characteristics must be accurately and speedily identified.
b. Initial stages of fire must be detected early, with high confidence but also with very low instance of false alarm, since such alarms create a massive response c. Patient and staff locations and identities, especially those near the fire, must be accurately and speedily reported Hence the value of this solution is that it provides accurate picture of the occurrence of a fire, the fire situation and of the location and identity of people (clinicians, patients, fire-response personnel and (via sensors only) visitors and non-badged people during transition into a fire emergency response situation, as well as providing an early accurate view to fire fighting response teams. In addition it can provide inputs to allow automated fire containment measures.

The inputs, outputs and functions for this service are given in Figure 15-5 R
Inputs - --------Facility information Functions Outputs Hospital grid map, zones and usage allocation including Pharmacy coordinates, zone, hazardous Fire detection, identification, material locations, fire first response team ;
members, FFR policy scoping and tracking, Clinical maximizing response and = Fire location and extent Patient status (evacuation issues) ---wi protecting life ~= Smoke, fire byproduct Context -Fire location, rate of spread Track spread of fire, fire location, extent and densities Smoke and toxic products extent and rate of spread products I = Location of all staff, = Hazardous material, flammable maierial location - Provide date to allow controlledl--.<' and type, especially near fire clinicians, patients, fire first Location, identity of staff, patients evacuation of people at risk ~
responders Evacuation risk for patients (patient condition, state Provide data to allow =
Fire response input data of patient treatment) ~ = Hazardous material Clinician role, activity responses to situation Equipment location, identity exposure situation - actual e.g. automatic dosure of fire and latent Environment doors, shut down, reverse or Fire location (sensors) Fire scope, spread othenMse optimize ventilation Smoke, toxic products spread >- system to avoid fire product Staff location and identity, especially near to fire spread, reduce airflow to fire Fire-trained staff location and identity i ...............................................................................
.......................................:
Patient location and identity, especially near to fire Figure 15-5 Code Red - Fire (E6) The primary ECAS contributors and enablers are: -Nortel Confidential 176 of 226 a) Initial fire or hot spot detection via sensors b) Patient and clinical staff location tracking to allow speedy complete evacuation from at-risk areas c) Support to hospital response - fire containment, patient and staff evacuation and confirmation of evacuation - through sensor measurements of extent and growth of the fire, spread of smoke and gaseous/toxic byproducts, location and tracking of staff, patients, Fire Response team personnel d) Communication of the current fire situation to fire response teams -providing details of fire scope, local hazardous materials (latent and actual), containment actions taken e) Supporting the fire response teams fighting the fire, tracking team member position, location, exposure to hazardous materials, situations, environmental factors Key environmental parameters that ECAS has to discriminate for this service are: -a) Fire detection (heat) b) Fire detection (light) c) Fire detection (Infra-red) d) Fire detection (smoke) e) Fire detection (combustion products) f) Fire byproducts spread detection (smoke) g) Fire byproducts spread detection (combustion products) h) Fire byproducts spread detection (heat) i) Location (fire) j) Location and ID (clinical and other staff personnel) k) Location and ID (patients) 1) Location and ID (general equipment) m) Location and ID (fire equipment) n) Location and ID (hazardous material) o) Location and ID (fire response personnel) p) Environment - fire response personnel Key Context parameters a) Fire location b) Type of fire and spread rate versus patient, clinician location c) Proximity of fire to hazardous materials d) Risk to hazardous materials e) Fire constraint actions (building automated, first responder then fire-fighter) f) Hospital evacuation plan and fire plan g) Clinical and logistics issues for patient and staff evacuation Nortel Confidential 177 of 226 h) Relocation destination for patients and staff at-risk from fire 15.7 Code Orange - Hazardous Material The objective of this application is to place the hospital on an emergency response footing in case of a serious hazardous material spill or leak, to ensure that persons are accounted for, to support the evacuation of persons from unsafe areas, to identify the location of the incident, track its changing scope and provide support to the initial steps taken to contain its impact as well as the overall containment and clean up process The key attributes of this application are: -f) Time critical a. The Hazardous Material Release (HMR) must be sensed and the nature of the HMR determined in its early stages b. Patients and staff potentially / actually in harms way must be identified, alerted and evacuated c. HMR Response personnel at risk must be flagged g) Fire assessment a. Accurate location of HMR and the evolving extent needs to be sensed b. Rapid early steps to contain the HMR can make later clean up and decontamination easier, minimizes damage c. Spread of toxic fumes, by-products must be tracked d. Nearby objects that represent a hazard in an HMR situation must be identified h) Security a. Patient identifiable clinical information not involved/hardly involved b. Physical security of the person and prevention of equipment loss, theft during chaotic time of emergency is an issue to be addressed i) Environment a. Track progress of HMR, fumes, byproducts b. Track location, scope, conditions for HMR response personnel c. Provide early alert for fumes and byproducts approaching unevacuated areas j) Dependability a. HMR location, characteristics must be accurately and speedily identified.
b. Initial stages of HMR must be detected early, with high confidence but also with very low instance of false alarm, since such alarms create a massive response c. Patient and staff locations and identities, especially those near the HMR, must be accurately and speedily reported Nortel Confidential 178 of 226 Hence the value of this solution is that it provides an early indication of an HMR
occurrence, provides an accurate picture of the evolving HMR, and of the location and identity of people (clinicians, patients, HMR-response personnel and (via sensors only) visitors and non-badged people during transition into an HMR emergency response situation, as well as providing an early accurate view to HMR response teams.
In addition it can provide inputs to allow automated HMR containment measures The inputs, outputs and functions for this service are given in Figure 15-6 Inputs Fadlity information Functions Outputs R
Hospital grid map, zones and usage allocation induding Pharmacy coordinates, zone, hazardous material HMR detection, identification, locations, HMR team members, HMR policy ~ scoping and tracking, Clinical maximizing response and Patient status (evacuation issues) HMR location and extent Context _l protecting life Toxic material, gases, Hazardous material release Iocation, rate of spread Track spread of HMR
products fumes, vapors location, To dc produds, gases or vapors extent and rate of spread extent and densiiies Hazardous material location, e es eciall near release Provide date to allow controlledl type Y = Location of all staff, Location, idenGty of staff, patients evacuation of people at risk Evacuation risk for patients (patient condition, state of dinidans, patients, HMR
paGent treatment) Provide data to allow first responders Clinician role, activity responses to situation = HMR response input Equipment location, identity - e.g. automatic dosure of fire data Environment = Hazardous material Hazardous materal release location (sensors) doors, shut down, reverse or exposure situation -Hazardous material scope, spread othennrise optimize ventilation actual and latent Gases, toxic, biotoxic products spread system to avoid HMR product Staff location and identity, especially near to HMR spread, modify airflow to HMR
HMR-trained staff location and identity Patient loc.ation and identity, especially near to HMR

Figure 15-6 Code Orange - Hazardous Material Release (E7) The primary ECAS contributors and enablers are: -f) Initial HMR detection via sensors g) Patient and clinical staff location tracking to allow speedy complete evacuation from at-risk areas h) Support to hospital response - HMR containment, patient and staff evacuation and confirmation of evacuation - through sensor measurements of extent and growth of the HMR, spread of dangerous byproducts, location and tracking of staff, patients, HMR Response team personnel i) Communication of the current HMR situation to HMR response teams -providing details of HMR scope, local hazardous materials (latent and actual), containment actions taken Nortel Confidential 179 of 226 j) Supporting the HMR response teams fighting the HMR, tracking team member position, location, exposure to hazardous materials, situations, environmental factors Key environmental parameters that ECAS has to discriminate for this service are: -a) HMR detection (chemical) b) HMR detection (gases) c) HMR detection (biotoxins) d) HMR detection (fumes) e) HMR detection (liquid) f) HMR detection (radiation) g) HMR byproducts spread detection (fumes) h) HMR byproducts spread detection (gases) i) HMR byproducts spread detection (biotoxins) j) HMR byproducts spread detection (radiation) k) HMR byproducts spread detection (liquid) 1) Location (HMR) m) Location and ID (clinical and other staff personnel) n) Location and ID (patients) o) Location and ID (general equipment) p) Location and ID (HMR response equipment) q) Location and ID (other hazardous material) r) Location and ID (HMR response personnel) s) Environment - HMR response personnel Key Context parameters a) HMR location b) Type of HMR and spread rate versus patient, clinician location c) Proximity of HMR to hazardous materials d) Risk to hazardous materials e) HMR constraint actions (building automated, first responder then HMR
containment, clean up crew) f) Hospital evacuation plan and HMR response plan g) Clinical and logistics issues for patient and staff evacuation h) Relocation destination for patients and staff at-risk from HMR, HMR
byproducts 15.8 Drug Theft Or Tampering Detection The objective of this application is to prevent drug loss due to theft, misplacement or damage due to environmental overstress while allowing legitimate movement around the hospital, and to allow legitimate clinician access. Continuous monitoring of the location of expensive, limited access medications and drugs, and environmental monitoring of Nortel Confidential 180 of 226 environmentally sensitive drugs will reduce loss and wastage. Detection of authorized, unauthorized personnel in vicinity of drugs in storage locations may provide an additional level of protection.

The key attributes of this application are: -a) Low latency a. Drug theft needs to be detected and stopped before theft is completed b. Drug tampering needs to be detected and stopped before tampered products enter the clinical workflow c. Drug misplacement needs to be corrected before third party finds drugs, d. Environmental stress needs to be detected and corrected before drug is damaged, or if the drug is damaged this needs to be logged and the drug marked for being discarded e. E.G. Thief stopped before exiting pharmacy or exiting building, drug cart location and thermal/sun loading environment tracked b) Security a. Access to this subsystem needs to be controlled to authorized personnel only - otherwise its information may aid in drug theft c) Dependability a. Theft and other unauthorized access needs to be identified with a high degree of confidence while avoiding erroneous alarms during normal clinical and pharmaceutical operations Hence the value of this solution is that drug loss by theft, misplacement/loss and damage due to improper storage or exposure to hostile environmental elements can be minimized or prevented It will provide an ability to locate and track drug carts, as well as major/expensive/narcotic drugs in hospital. As a result it provides an ability to monitor and control access to restricted access drugs. Drug (container) RFID (or Bar Code) labeling on individual dose containers would also allow the routine application of closed loop drug administration for patients.

The inputs, outputs and functions for this service are given in Figure 15-7 Nortel Confidential 181 of 226 Inputs Facility information Functions Outputs Hospital grid map, zones and usage allocation R
induding Pharmacy coordinates, zone, Drug cart ~1 Drug safety, security and routes, route history, drug storage sites Clinical - environment Clinician ID, Drug ID, quantity (by RFID scan, Tracking whereabouts of r" =
Drug location, inventory manual entry), Pharmacist ID, Patient ID drugs through the chain from = Alerts for misplaced drugs, Context unauthorized drug movement = Clinician role, authenGcation, authorization s 9 to pharmacy to = Alerts for drugs approaching Clinician/drug/patient association at administration I
patient administration stale date"/support to Patient drug history, drug regimen -i - Protecting drugs from properly sequence drug Zone boundaries of pennitted movement or use ~ usage Drug environmental safety (from drug type and misplacement, theft or being I =
Alerts for drugs exposed to sensed drug environment) ex osed to harmful Environment p limit environmental conditions Drug cart ID and location " environmental conditions = Support for validated safe Drug ID (RFID) on cart or before administering - Enabling drug inventory drug administration to Drug location (by RFID reader location) patients act Packaged drug quantities in stores, on cart (RFID) .......... actPV plties Sensodrug cart and drug store environment - SU orting safe validated possible individual drug package environment - by administration procedures RFID sensors J .......... . . . . . . . ............. . ...................... . . . . . .
. . . . . . . . . . . . . . ..............................................

Figure 15-7 Drug theft, damage or tampering detection (E8) The primary ECAS contributors and enablers are: -a) Tracking, identifying drugs by their container tags at each location, identifying when drugs are moved and by who-what authorization b) Identification of drug movement with/without associated authorized clinical personnel c) Validating ongoing safe environment for drugs - sensor networking required d) Location of RFID readers during act of read and proximity of RFID readers to clinical personnel to determine who is reading the drugs and location of inventory Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (drug cart, major drug containers but not every single pill) by location system + RFID readers, RFID tags b) Sensor (thermal, possibly light/UV, possibly humidity/water) at the pharmacy, pharmacy storage shelf/closet/refrigerator/freezer level and on the drug carts within the rest of the hospital Key Context parameters a) Drug type, value/categorization b) Access restrictions c) Required drug environment d) Actual drug environment e) Drug location f) Location of drug discriminated by zone Nortel Confidential 182 of 226 g) Drug status - in storage, on cart for distribution, at distribution point/administration point h) Drug cart location, i) Proximate clinicians ID, role j) Proximate patients, ID
k) Clinician proximity vector 1) Clinician drug access rights and privileges 15.9 Equipment Theft Or Movement Outside Of Authorized Zone - Detection The objective of this application is to provide a current view of equipment and terminal location with sufficient accuracy, latency and confidence level that theft in progress can be detected swiftly enough that it can be prevented from completing.
Additionally, equipment tied to a particular area, department or zone cannot be silently removed from that zone by unauthorized personnel including unauthorized clinicians, but can be moved by authorized personnel, and can be tracked wherever it goes within the facility. These services must be enabled without impacting clinician workflow, including legal clinician/employee export of equipment, terminals from allocated zones.

The key attributes of this application are: -a) Continuous tracking and monitoring operation - system coverage and availability are important b) To allow equipment to be located when needed, equipment and terminals to be tracked for inventory, service delivery and authentication purposes (routine application) and to prevent equipment and terminal (especially hand-held terminal) loss, "wandering' and/or theft the equipment and terminals must be continuously trackable c) Time critical - the location tracking and context analysis and determination that equipment is in an emergency situation (theft in progress, wandering or loss) must be made in time to take steps to prevent the theft completing and in time to correct a wandering or loss situation - this may include a loss situation where the device is static and its allowed zone moves with a (forgetful) clinician d) Security - must provide appropriate information to appropriately authenticated users but be secure against providing location and location status information to others since this may allow the system to aid in equipment theft - "where is the valuable equipment" and "have I been detected yet?" are two pieces of information that must not be available to potential thieves.

e) Dependability - the system must dependably discriminate between lawful and authorized, authenticated equipment movement and use versus unauthorized Nortel Confidential 183 of 226 equipment movement for non-criminal purposes inside the facility versus theft by third parties Hence the value of this solution is that ongoing multi-item tracking activity provides a degree of Theft prevention through detection, which allows cost savings, and allows services using "thievable" items to be introduced (e.g. WLAN PoC). Equipment "borrowed" from another department in an emergency can be tracked and assigned to the "borrower" with a prompt for them to return it or alternatively other facility policies about moving equipment between departments can be applied. Equipment can rapidly be located within the building reducing lost equipment levels, allowing better utilization and reducing the need for capital equipment expenditure. Equipment can be located for inventory, servicing or condition validation purposes. Equipment can be automatically logged out to authorized exporters when it leaves the building. (Note - not all of these are emergency services - but theft prevention is and in some circumstances tracking and locating "borrowed" equipment can be, since this leaves the "donor" department without the use of that equipment.) The inputs, outputs and functions for this service are given in Figure 15-8 Inputs Facility/clinical information Functions Hospital grid map, zones and usage allocation: Outputs Equipment utilization history Equipment I clinician I patient Clinician ID's, roles, profile , = Equipment "no-go" zones - " association Context - Processing of raw location data Equipment ID's to determine prOXlftllty = Clinidan/patient, Zone boundaries of permitted equipment dinician/equipment and movement or use conditions patient/equipment Equipment utilization primitives Establish , track role of CliniCian proximity event Clinician terminal type and connedivity Clinician role by zone with patient by zone inference charaderistics Environment - Establish hist0 of roxlmlt = Proximity event location tY P Y and zone, inferred Clinidan location vector primitives Patient location vedor primitives events for each proximity possible range of Equipment location vector primitives r--+combination \_ situations Any probmity detedor outputs with parametric : Determine equipment data ( range, ID of parties Equipment condition, environment and authentication utilization (sensors) Figure 15-8 Equipment theft or movement outside of authorized zone (E9) The primary ECAS contributors and enablers are: -a) Equipment location and tracking b) Personnel location and tracking c) Equipment identification primitives collection d) Personnel identity primitives collection e) Mapping of equipment track f) Determination of zone boundaries including proscribed zones including building and/or area entrances and exits, equipment where terminal operation could be hazardous, hospital security personnel location g) Mapping of equipment location to boundaries and determination of status Nortel Confidential 184 of 226 h) Association of equipment with personnel i) Determination of personnel authorization - from facility database j) Calculating context situation and communicating result Key environmental parameters that ECAS has to discriminate for this service are: -a) Location (equipment/terminals) b) Location (personnel) c) Location (clinicians) d) Location (security personnel) Key Context parameters a) Equipment/terminal location by zone b) Zone-based policies for that equipment/terminal c) Prior and current terminal or equipment association-for-use to clinician d) Location-based equipment/terminal status e) Equipment associations with personnel - clinician and others f) Terminal or equipment moving without being associated with personnel -theft g) Terminal or equipment moving without being associated with authorized personnel -"wandering" or, if it enters an exit proscribed zone, possible staff theft h) Personnel authorization to transport equipment Nortel Confidential 185 of 226 16 Appendix - Detailed Drill Down On Selected Application Areas This section will expand several of the application descriptions given earlier in Section 7 to allow them to be used as scenarios or use-cases for a more detailed solution design.
Three very diverse examples will be chosen for this. They are: -a. R3-Equipment tracking, location and condition b. R5-Clinician Point of Care communications c. E1-Code Blue Figure 16-1 Scenario Interdependencies for detailed drill downs Figure 16-1 shows the relative locations of these and their interactions with the rest of the applications suite.

R3 - Equipment tracking, location and condition is a basic location or location and sensing service with a broad applicability across many areas, both in healthcare and elsewhere. In itself it does not have to meet Clinical Grade requirements but, when used as an infeed into Clinical Grade services and applications, it is subject to the implied Clinical Grade requirements rippling down from these applications into R3-Equipment tracking, location and condition. R3-Equipment tracking, location and condition can exist in a variety of forms from a basic equipment location service purely inputting to client Nortel Confidential 187 of 226 services or as a relatively sophisticated location, tracking, association and condition/environment monitoring capability. Here two alternatives will be considered, being the basic location service and a condition-aware extension. Self contained associations will not be considered here this is covered under R4-Equipment/Clinician, Clinician/patient or Equipment/patient association in this document.

R5 - Clinician Point of Care communications is probably the most significant and broadly used routine clinical application of all the applications analyzed here. As such it has to h fully meet Clinical Grade requirements and has to be truly optimized into the Clinicians' environment, since any limitation or flaw would be multiplied several thousand-fold by the high degree of use of this critical clinical capability.
PoC
communications will test any solution design for its ability to deliver complex Clinical Grade context aware and location aware services en masse in multiple parallel and simultaneous sessions.

El - "Code Blue" will test the ability of any solution to rapidly and without notice form a Code Blue team, based on a complex context algorithm based on clinician location, event location, clinician skills, current tasks and availability, etc. and then to support that team, in this instance with a PoC-like capability, albeit in an emergency situation.

In addition, while Code Adam will not be drilled down in the same depth some additional results will be included, specifically in Table 16-2.

E2 - Code Adam is a non-clinical emergency situation addressing an extremely urgent, high visibility remediation of an emergency condition. It requires a rapid location aware and context aware result to be generated and actions taken based upon that result. Of course the ideal action is to detect the very earliest part of a potential Code Adam and to alert the situation before it becomes a high profile incident. At the same time the Code Adam algorithm must not prevent lawful interaction with the protected patients since this would interfere with routine clinical workflows. Hence this service tests the accurate discrimination of the situation - genuine Code Adam detection versus not alerting for normal interactions with the protected patients.

We will now explore each of these three example "drill down" applications or services in more depth than was the case in the earlier sections.

16.1 R3-Equipment tracking, location, condition The application objective for R3-Equipment tracking, location, condition monitoring is to provide unobtrusive workflow integrated, workflow supporting tracking of clinical equipment and portable terminal equipment location, as well as optionally tracking its physical environment and/or its condition and fitness for use, as an input to computing the equipment situation and tracking equipment as an input to clinical services as well as for inventory and theft protection purposes. As such the application can be defined to be a basic location monitoring service or can be expanded to include contextual tracking of Nortel Confidential 188 of 226 equipment with association or tracking equipment condition and location, via integrated sensors and/or telemetry functions in addition to the location tags. This application will support multiple other client applications and some aspects of its requirements will depend upon which other applications are clients. The basic equipment location capability will be used by multiple client applications while the addition of sensors and location allows equipment condition and utilization to be tracked. This also allows maintenance to be scheduled adaptively when it is needed rather than on a fixed schedule whether it is needed or not.

The attributes of the equipment location or the location and tracking or the location, tracking and equipment condition monitoring service depends upon the nature of the client services, their attributes and their input requirements. For instance a basic location service for inventory control purposes may require an ability to locate a piece of equipment to a precision of a few meters since this will be good enough to place it within a particular room and the service latency can be of the order of many 10's of seconds or even several minutes since it is unlikely that the equipment would be moved in that timeframe, especially if the equipment was in storage in is not being used. On the other hand, equipment location information used as an input to the clinician-equipment association service which is associating equipment to a busy mobile clinician would have to be precise enough and accurate enough to allow the discrimination of whether the equipment is within the clinician's personal zone, which is at best a semi-circle of less than a meter radius and hence its precision would have to be substantially better than a meter. Furthermore the error rate for false association of equipment with clinicians has to be very low requiring a high accuracy since a false association may either enable a service to the wrong user or may deny service to a legitimate one. In addition, once a clinician approaches an equipment he or she does not want to wait while the system discovers the new association so the solution latency must be low, certainly of the order of a second or less. This is also true for applications which use dynamic differential location tracking to maintain or terminate association and by implication to maintain or terminate sessions. Here it is low latency differences between personnel and equipment tracking that is also important.

This accuracy, precision and latency has to be maintained while the location service is in continuous and widespread use throughout hospital in tracking equipment for various purposes, and the high usage also increases the visibility of an unacceptable accuracy or location error rate. Since the location service will also provide implied context aspects derived from dynamic location and proximity measurements the location service latency must also be appropriately low. This is particularly significant for hand-held terminal theft protection.

Here the system must respond in time to prevent theft during the early stages of the theft attempt, both in terms of determining the situation (the terminal is now moving independently of its authorized handlers) and in terms of tracking a fast-moving "unaccompanied" terminal moving in the hands of a thief through the facility.

Nortel Confidential 189 of 226 16.1.1 Requirements - qualitative and quantitative The following are the key qualitative requirements for a location service capable of feeding multiple other higher level services with an adequate quality of information.
Accurate tracking/location of all tagged items of equipment requires spatial precision of location in both 2-D and in 3-D space that is adequate to meet the needs of client application suite, including equipment-personnel proximity/association (which itself provides a service to client applications such as PoC communications), theft protection, wandering equipment protection, inventory control and equipment location, especially rapid serviceable equipment location in an emergency clinical situation, as well as background location for maintenance purposes. The latency or currency of location in the time domain adequate to meet the needs of client applications, especially equipment/personnel association, theft protection, equipment location in support of a clinical emergency where stringent time constraints will exist. The mapping of equipment location to zones requires the determination of location of such equipment to be inside or outside such zones and in some cases requires the tracking of equipment trajectories near the boundaries of such zones. For example equipment passing by the entrance/exit zone of the hospital presents a different situation to equipment entering the entrance/exit zone.
Under these circumstances the accuracy, precision and latency of the location tracking information must be adequate to avoid the misinterpretation of the situation.
In the event that the location service is extended to provide the sensor/telemetry-based functions of equipment health and environment monitoring then the sensors, equipment usage logs, and collection points need to give an accurate enough assessment of the equipment utilization, treatment and environment that an adaptive maintenance scheme can be derived to replace the fixed cycle scheme without degrading equipment dependability and that, in a medical emergency, the clinicians or other equipment seekers can be guided to the nearest available, functional and "fit for use" equipment and not just the nearest equipment, irrespective of whether it is in use or is fit for use.

A hospital may comprise a single building or may consist of a campus with several large buildings. In this latter case the location system must enable tracked transfers between buildings on the campus.

To cover most hospitals the number of medical instruments and equipments tracked will be in the range of 100's to 10,000's. Each piece of equipment needs to be located and identified, possibly also to have its condition reported with a precision, accuracy and latency suitable for the client applications. Since these client applications have differing and often conflicting requirements (e.g. Client #1 may need extreme precision but doesn't have stringent latency requirements, Client #2 may need very fine time resolution requirements, medium precision needs but high accuracy needs, Client # 3 may need another combination) the needs of the overall client applications combined with the number of items to be tracked can produce an enormous amount of data.

For instance 10,000 units, each being tracked and located 10 times a second to meet possible stringent latency requirements would produce 100,000 location and identity primitive reports per second, or 360,000,000 such reports per hour. If each location and Nortel Confidential 190 of 226 identity primitive sample is a mere 16 bytes of data (2 bytes header, 2 bytes tail, 6 bytes location allowing 10 cm resolution within a 400 meter cube, 2 bytes ID
allowing 60,000 ID's, 2 bytes spare) then this corresponds to 5.76GBytes/hour.
Yet for background inventory purposes it may be useful to know where everything is once per month, equivalent to a useful data rate of 10,000/24 x 30 = 14 reports per hour (or 224 bytes per hour). Hence the location system has the potential to generate a large amount of data that is not useful information, in that client applications will not use it all.
This leads to the concept and need for selective filtering of the data to achieve just enough data flow into each of the client applications to meet their needs without triggering excessive processing or excessive data discarding within those applications.
The level of precision required is around 1-3 meters for many client applications which need room-level discrimination but the precision requirement is much tighter, perhaps as tight as a few tens of centimeters for personnel/personnel and personnel/equipment proximity applications (e.g. for clinician/equipment association).

This can be achieved by two methods being: -a. The use of a broad coverage highly precise location system b. The use of a less precise location system such as WLAN location, augmented by proximity detection between proximate objects or people Both of these have significant challenges and shortfalls.

Another significant parameter is "coverage", the amount of the facility or hospital where the location system functions within design parameters. It is not necessary for the location system to function in every square centimeter of the facility but in those areas where coverage is required the coverage of those areas must be virtually complete, perhaps of the order of 99-99.99% coverage, dependent upon the requirements of the client applications. Furthermore the client applications must be able to function without 100.000% location coverage since this is likely to be impossible to obtain.
The actual level of coverage required will depend upon the nature of the client application as well as the impact on that application of a lack of 100% coverage. As an example a low coverage of say 60% at or near hospital exits would degrade the theft detection/prevention client application but would still detect enough thefts that the local criminal element would likely be deterred, while a coverage of 99% in a PoC encounter scenario would result in 1% of PoC events having to complete without the benefit of location and hence location association or proximity data. In a medium sized hospital there may be 10,000-20,000 PoC events per day so this would lead to 100 -200 events per day which were noticeably different to the others or which failed to complete. "Noticeably different"
may be acceptable to clinicians, depending upon the nature of the difference (e.g. an unexpected authentication request 1% of the time) but a "failure to complete" at a 1%
level would likely prove unacceptable to clinicians. Hence this puts a requirement both into the location system to provide high coverage and into the client applications to be able to function, perhaps sub-optimally, but always safely and securely, without complete location information.

Nortel Confidential 191 of 226 ''~.Client App R4 Equip't/ E9 Equip't R5 Point of El Code E6/7 Code R7/E8 Drug clinician/ wander / Care comms Blue Red / safety and theft Paramete7-l.` patient track theft Orange detect Number, type 2,000+, all 500+ 100+ peak 10-20 (staff Up to 500? 50 (drug carts), of equipments types terminals, Usually a lot plus pharmacy, crash cart, less ward drug closets etc.) Location 1-2 meters +/- 1-2 m +/- 1-2 m -5 m--> 1-2 m 2-5 meters for 1-2 meters precision (which room) (absolute), (absolute), (absolute), 30- nearby, non-(absolute) , 30-50 for absolute, +/- 30-50 cm +/- 30-50 cm 50 cm involved cm (associative +/- 30-50 cm (proximity) (proximfty) (proximRy) equip't, 30-50 proximity for drug (proximity) cm for involved admin) equip't Location Sub - second Sub-second Sub-second Seconds -) Sub-second to Few seconds latency (300 ms?) (300 ms?) (300 ms?) Sub-second few seconds (absolute), sub-(300 ms?) second (proximity) Dependability 4 9's? 2 9's 4 9's 3 9's --) 4 9's 3 9's? 3 9's?

# of 7-10,000 Wander-50- 3-5,000 Low (140/yr V Low Admin 1,000, theft events/day 100, theft 1-5 blue + pink) - low # overlapping 50+ A few 20+? Not common Very rare Common - 2 -5 events simuttaneous Precision of High - Wrong Medium - High - Wrong High - Wrong Med - more High -correct identity clinician/wrong theft detection clinician/wrong clinician/wrong important to drug admin, equipment = more imPortant equipment = equipment = assess overall medium for theft si nificant risk than what is si nificant risk si nificant risk situation g being stolen g g Battery life - Equip't maint Equip't maint Equip't maint Equip't maint Equip't maint Equip't maint tags cycles - cycles - cycles - cycles - cycles - cycles -many months many months many months many months many months many months > Requirements - quantitative for Hospital X

Table 16-1 R3-Equipment tracking, location, condition Table 16-1 shows the first pass of estimates for quantitative requirements on the R3 -Equipment tracking, location and condition monitoring application based upon the needs of 6 very different client applications. The data shown here is preliminary and requires confirmation in ongoing clinical workflow and traffic analyses. These will take considerable time and effort and may be part of planned academic research.

Figure 16-2 shows the input interdependencies into the R3 -Equipment tracking, location and condition monitoring application. As can be seen from this Figure the R3 application may be the source of information (or at least data from which information is derived) to many client applications but is not dependent upon any of them, only being dependent upon information from the hospital databases. Hence R3 is a root application or base application on which others are built.

Nortel Confidential 192 of 226 r------------------------------------ ~
HIS HCIS Hospital Clinical, Facility Clinician Patient Patient FacilitV, Staff and data data data Clinical data Patient databases ------------------------------------ and infrastructure ~
........................._........_............................................
....-....._..._....__...._..._.

To client applications R3 - Equipment Basic tracking, location Environmental and condition Awareness ------------Figure 16-2 Scenario Interdependencies For R3- Basic Equipment Tracking Figure 16-3 shows a flow diagram for various versions of R3 from a basic location function to a full location tracking, zone mapping and condition monitoring function as well as showing how it, in conjunction with R2 (or R1) can interact with R4 to produce proximity information in the case of clinician/equipment proximity.
-------- -- ---- ----- ---- ----.._. --------------------------Equipment E9.U.P__ Sensors Tag m..__ent .
Basic ; condition/ Senslydata location Location environment receivers receiver system a) Receive equipment condition, a) Receive location, usage, environment primitives identity primitives b) Compute condition, ~:.
b) Compute spatial Out of bounds environment, usage location, confirm identity equipment Condition, _______________________ conditions environment, gtore,, -' c) Compare against limits usage prior Prior Environment limit measurements . c) Compare with previous for equipment OK Not OK
location location, identity Usage history BaSIC d) Establish vector Appropriate protocol tracking or pohcy applied ----------_ ____,,.:_. ._-__------ ------- -- --- --- ------------ _........_ ----- -LLZone map----;ejEsta6fi fi`focation, vecfor--refative to Zone map Zone based Zone, equipment -` f) Apply Zone map based In list end location policies maPP...-g ;
policy OK & Context :
NotOK ..............
-------------------- ----------- ---------------, .~'`------Proximi Establish proximity to clinician *-- Input from y (location, vector) clinician location I!K41 Not proximate Proximate Theft protocol and Clinicianlequipment protocol policy applied and policy applied '--------------------------------------------------------------------------------' Figure 16-3 R3-Equipment tracking, location, condition Walkthrough Nortel Confidential 193 of 226 16.2 Application #2 R5-Clinician Point of Care Communications The application objective for R5-Clinician Point of Care Communications is to provide unobtrusive and workflow integrated, workflow supporting communication of data to/from the PoC in a secure, easy to use manner to help make Point of Care clinical episodes more effective, safer and more secure. The basic attributes of Point of Care communications were covered in 14.5 16.2.1 Qualitative and Quantitative Requirements For A Point of care Solution The qualitative requirements for PoC are mainly derived from the fact that it is intended to be used as part of decision making and decision execution in patient treatment by delivering data and capturing data during the Point of Care encounter and hence must be reliable, dependable, accurate, non-intrusive, easy-to-use, informative and secure. Any ECAS aspects must meet these requirements too, putting demands back into the accuracy, precision, latency and security of the environment and context functions. In terms of the security and privacy of information the system can only provide data to properly authenticated clinical staff whose profiles show that they have good reason to access that patient's data. Furthermore a high level of security is required to block attacks which not only threaten privacy but also the basic integrity of the data held within the medical records systems. Privacy requires security against both the illicit viewing of data and theft of data - both theft of data due to non- authorized network access and theft of data due to theft of a physical item (e.g. a hand-held terminal) containing that data.
Privacy also means blanking data on active terminals when the clinician is absent and eventually auto-suspending or auto-terminating the session if the clinician is absent too long.

The performance of the PoC solution is required to be such that consistent rapid system responses are possible at latencies suitable for integration into a high pace high stress clinical workflow situation, especially in times of emergency. The system performance must meet the end user needs in the context of the end user situation. In addition the system must be dependable, always delivering the correct data (right patient, information compatible with the user's authentication and "need to know", etc.), in an adequate response time to the correct location/user, in a form compatible with the user's terminal and with high integrity.

The system must perform at a level that the end users trust it to deliver allowing it to achieve high usage, which in turn leads to users reaching a state of unconscious competence in its operation and turning to it automatically, which will enable its true integration into clinical workflows. Ease of use is vital since not only is it the path to high usage, but also a lack of distraction from mainstream clinical thought processes by end users will result in better clinical decisions and less clinical errors or repeat work. Both the system behaviour and hand-held terminal characteristics must be "right" so as to allow the clinician to focus on the clinical issues. The hand-held, where used, must be low weight, rugged, be easy-to-use and have an adequate screen/display size and resolution in the context of the user needs and the application. The unit battery should Nortel Confidential 194 of 226 ideally last for more than a shift or alternatively the battery or entire unit must be speedily interchangeable within a natural shift break - e.g. a coffee break Some quantitative strawman requirements for a mid-sized hospital might be: -d. Number of active clinicians in one shift = 400 max - 80 physicians, 320 nurses e. Number of in-patients = 400 - Number of POC encounters per in-patient per day = 3 major clinician-patient, 12 minor clinician-patient & 6 clinician-clinician f. Number of out-patients = 200 - Number of POC encounters per outpatient per day = 1.5 major clinician-patient, 3 minor clinician-patient and 2 clinician-clinician From this there would be 400 x 3 + 200 x 1.5 = 1,500 major clinician-patient events per day, 400 x 12 + 200 x 3 = 5,400 minor clinician-patient events and 400 x 6 +
200 x 2 =
2,800 clinician-clinician events, of degree 2.2 (average 2.2 clinicians per event), resulting in 6,160 clinician-clinician event experiences for the clinicians.

At this time and with only limited information the POC encounter characteristics assumed are: -Major - may last a significant time, perhaps 5-30 minutes, and require multiple transactions, including fetching several diverse data files, some of which will be large and inputting several items of data, decisions and orders. For the current work an average duration of 12 minutes will be assumed.
Minor - usually will last for a short period and will download limited data, may upload a few specific data points (e.g. vital signs). For the current work an average duration of 3 minutes will be assumed.
Clinician-clinician - when this supports consultation the session may be quite protracted, when used to request a specific item or service or to provide a specific item or service the session may be quite brief. For the current work an average duration of 4 minutes will be assumed.

This leads to a total PoC encounter time across the hospital of: -Major clinician-patient PoC 4 1,500 x 12 = 18,000 minutes Minor clinician-patient PoC 4 5,400 x 3 = 16,200 minutes Clinician-clinician PoC clinician minutes 4 6,160 x 4 = 24,640 minutes Total .................. ......... ...................................58,840 minutes of clinician-time For the 400 clinicians this corresponds to an average of 147.1 minutes per clinician or nearly 2.5 hours per day. But averages can be deceiving since many of the major PoC
sessions will fall of the 60 physicians.

Nortel Confidential 195 of 226 If we assume that 80% of the major clinician-patient PoC sessions fall to physicians and that they are equally represented in the rest of the PoC events then each physician's PoC
duration per day would be: -Major C-P PoC 4 18,000 x 0.8/80 = 180 minutes Minor C-P PoC 4 16,200/400 = 40.5 minutes C-C PoC 4 24,640/400 = 61.6 minutes Total .................................... ...282.1 minutes (or 4.7 hours) Under this model the nursing PoC level would be Major C-P PoC 4 18,000 x 0.2/320 = 11.2 minutes Minor C-P PoC 4 16,200/400 = 40.5 minutes C-C PoC 4 24,640/400 = 61.6 minutes Tota1 ..........................................113.3 minutes (or nearly 2 hours) Both of these numbers, if validated, are significant percentages of these busy professionals professional lives and require that the system indeed meet the requirements outlined above.

Furthermore, with a total PoC session duration across the 3 types listed of 18,000 +
16,200 + 11,200 = 45,400 minutes of session time, the average number of simultaneous sessions would be 31.5, when averaged over a 24 hour period. But if we assume that 75%
of these sessions occur during an 8 hour period, then the average for that period would be 45,400 x 0.75/8 x 60 = 70.94. Allowing for a peak to average ratio of 3:1 this would suggest that the hospital PoC solution should be dimensioned to allow a peak of at least 200 - 220 simultaneous sessions, or allowing for a peak to average ratio of 2:1 the solution should allow a peak of at least 140-150 simultaneous sessions.

ECAS can contribute to enhancing PoC functionality and effectiveness in several ways.
Location awareness allows more and better context-based decisions to be made, based on clinician-patient physical proximity, PoC location, etc. Examples would include: -g. The pre-fetching of patient records or priority presentation of patient records appropriate for the patient proximate to the clinician h. The pre-fetching of patient records or priority presentation of patient records appropriate for the PoC encounter location i. The pre-fetching of patient records or priority presentation of patient records appropriate for the PoC encounter clinical situation (e.g. pre-op, during op, post-op, recuperation or pre-discharge check) j. Establishment, maintenance of and suspension/tennination of an authenticated session based partially on the proximity of the clinician to the patient or the clinician to the terminal k. Pre-configuring or validating equipment to be used at the PoC encounter 1. Locating equipment required at the PoC encounter and optionally validating the equipment availability, fitness for use Nortel Confidential 196 of 226 m. Mapping clinical data to best meet the capabilities of the communications device available to the clinician n. Computing session migration opportunities in the event that data incompatible with the clinician's terminal has to be delivered - an example would be the delivery of a radiology image when the clinician is using a small hand held terminal - in this case the session would have to be migrated to a nearby and available large screen monitor o. Blanking the clinician's hand-held should the clinician leave it lying around and detecting its theft, taking steps to ameliorate the impact of the potential theft, including disabling the device, blocking access to the device stored data, and directing security personnel to the vector of the device In general enhanced context awareness in a smart system solution will allow for better context-interpreted responses from the system which can provide for more effective, speedier, convenient PoC sessions. It is anticipated that this would lead to a higher clinical productivity and lower clinical error rates, since the tools, being easier to use, more intuitive and quicker to use, will generally be used more intensively.

16.3 An Example Point of Care Application Scenario Using ECAS
Caution - This is based on a coarse work-flow analysis which needs validation.
The scenario we will examine is a simple one, being "A physician examines a patient with a broken arm, places treatment order and prescribes pain killing medication".
This scenario will be examined from three perspectives, being: -Perspective #1 - What an external observer would observe Perspective #2 - The clinician activity perspective Perspective #3 - ECAS-based PoC system activity 16.3.1 Perspective #1 - External Observer view of example walkthrough The physician enters the patient room carrying a hand-held device. The patient, who is wearing an admission badge is already in the room and is complaining of extreme pain in his right arm. The clinician hand-held device is already actively associated to the clinician since secure access had previously been negotiated via terminal ID, type, maintained due to clinician/terminal proximity during an earlier session and the device has not been separated from the clinician. The device automatically locates the patient profile associated with the clinician's privileges triggered by the physical proximity of the patient and the clinician. The physician calls up a chart on a hand-held device by confirming that the patient option presented is correct. The physician examines the arm Nortel Confidential 197 of 226 (carefully -it hurts) and then the physician calls up the x-ray image taken earlier in the treatment as a result of an earlier order. The resolution of the hand-held device is inadequate to display such an image and so the clinician is advised of this fact and of the location of a nearby free radiology terminal which is down the hall. The location and availability of the radiology display is transmitted to the tablet. The physician notifies the patient that he will be right back and exits the room. The application session is continuous as the physician walks down the hall; the image is queued and waiting at the radiology monitor. As the clinician reaches the monitor it greets him and requests a simple confirmation that the clinician wishes to view the monitor. Upon that confirmation the clinician gains access to the monitor and the queued image. Upon examination of the image the physician confirms fracture and, due to its nature, books theatre-time for surgical realignment later that day on his hand-held device which has remained in an authenticated session since it has not been separated form the clinician. The physician returns to the patient, confirms the patient's fears that the arm is broken, tells the patient what the remedial steps will be and prescribes a pain-killing drug. The drug order is sent to the pharmacy for priority dispatch and administration to the patient. The central records system raises a flag back to the clinician, based upon suitability of that drug for this patient and suggests an alternative (in this case this was triggered by the database having access to the patient's drug history and discovering something that the patient should have told the physician when asked but did not). The physician accepts the recommendation and notifies the patient that a nurse will be along shortly to administer a pain killer. The act of accepting the recommendation by the physician triggers the pharmacy to dispatch the prescribed drug to the nurse's station and sends an alert to the nurses' station that the drug is on its way and is to be administered immediately. The doctor and nurse never see each other. When the drug arrives the nurse administers the drug after verifying system has identified correct patient. The administration is automatically verified and events are logged.

16.3.2 Physician Operation during Example - Walkthrough -with ECAS

The physician enters the patient room carrying a hand-held device which has not left his side since he logged on and he sees the patient who is already in the room and is complaining of extreme pain in his right arm. The device automatically offers the appropriate patient files associated with the clinician's privileges to the clinician. The physician examines the presented Current Event history record on his hand-held terminal to see what has been diagnosed and carried out for THIS event and notes that an X-ray has been taken. The physician decides to examine the X-ray image and enters a request for the X-ray result. He receives a message indicating the hand-held device cannot display this image, and is notified of the location and availability of the nearest available radiology display. The physician advises the patient that he will be right back and then the physician walks to local large display, where after acknowledging a greeting form the display the physician views the required image. The physician confirms the fracture on the large screen monitor and books theatre-time for surgical realignment later that day on Nortel Confidential 198 of 226 his still authenticated hand-held device. The physician walks away from the large screen device automatically triggering termination of large screen session. The physician returns to the patient, advises him of the diagnosis, the treatment plans and prescribes pain medication. The physician enters a pharmacy order for a pain killer but the system queries the request, flagging a possible contra-indicating condition that the physician was not aware of. The physician changes the medication order, either by accepting a system recommendation or by entering another not-contra-indicated choice. The physician receives a confirmation that the order has been received at the pharmacy and at the local nursing station. Since this Physician-patient interaction is finished, physician leaves for next patient taking his terminal with him - he stays authenticated to that terminal ready for the next encounter due to continuous proximity between the physician and the hand-held terminal. The doctor and nurse never see each other, but later the nurse enters the patient's room with the drug, validates detected patient proximity, and the drug dosage and timing then administers the drug. The administration is verified and events are logged.
16.3.3 ECAS-based PoC System Operation during Example -Walkthrough The physician enters the patient room. The physician is carrying a hand-held terminal that he was authenticated on to earlier in the day and which he has not been separated from by very far for very long so the unit remains authenticated to him. Continuity of authentication through proximity is continuously tracked, even through WLAN
and location system AP changes or changes between various wired, wireless systems or wired and wireless terminals. The ECAS network had previously recognized the hand-held type and identity, the user ID and had set up an appropriate profile, session adaptation, and user privileges.

By this time the Clinician terminal has been in proximity with the patient long enough to establish a positive association - in human terms this should be almost instantaneous -say a second or two at most. The patient is complaining of extreme pain. The physician consults with his authenticated terminal which offers him an option to view this patient's event history.

Upon his acceptance by presenting a pre-arranged indication (possibly he touches a biometric authenticator on his ID badge) the system presents the information to date about the overall hospital encounter with the patient of which this clinician encounter is one (but not the first) event. The system achieves this by identifying two proximate pair situations (clinician-patient and clinician-terminal), confirming the identity of the physician and of the patient as well as the clinician's right to interact with that patient at that time. The identity and proximity of all parties being associated is established based upon the patient tag, the clinician tag and the authenticated terminal tag being "proximate" and the ID primitives being mapped into personal ID's, which are then used to search the HCIS clinician/patient association database and clinician privileges and authorizations database. The PoC system then delivers the appropriate clinical data as approved by the context engine assessing the results from those database scans.

Nortel Confidential 199 of 226 The physician examines the Current Event history record to see what has been diagnosed/carried out for THIS event and notes that an X-ray has been taken.
The physician enters request for the X-ray resultant image to be sent to him. The system receives the request, validates it against the clinician's access privileges, identifies its location (radiology database) and fetches it. The system notes that file is incompatible with the display properties of the clinician's current terminal (a hand-held device) so caches the image file, identifies the nearest large screen display which is not being used, formats the data of the image for that display, books the display for the use of the clinician, and generates message to the hand-held advising the physician of the location of the display.

The physician receives (and acknowledges) the message indicating the hand-held cannot display the image and that he will accept the image on the large screen display. The location system tracks the physician and his hand held terminal traveling to the display.
On detecting that physician is proximate to the terminal, the system downloads image to the blanked terminal and causes the terminal to display a greeting for the clinician. On the physician accepting the greeting the display is activated with the requested image. All the time the session on the hand-held terminal is maintained since it has not been out of proximity with the physician.

The physician exainines the displayed image and annotation notes from the radiologist, confirms the presence of a fracture and books theatre-time for surgical realignment later that day on his hand-held device, which in this instance has maintained its session.
Alternatively the whole session could have been transferred to the large screen terminal and the theatre booking made there. Either way the system accesses the theatre booking roster, identifies the earliest time that an appropriate theatre is available for an adequate duration and with adequate staffing, anesthetists, etc. The system sends physician confirmation of time, location, logs it into his personal schedule.

The physician walks away triggering automatic termination of the large screen session, and either transfer back to hand-held or continuity of the hand-held session, depending on whether the overall session was migrated in the first place. Note that the system has to allow easy secure access, roaming between WLAN cells, nomadicity between terminals, mid-session terminal type changes along the way.

The location system tracks the physician and his hand-held terminal as he returns to the patient, advises the patient of the findings and treatment options and prescribes pain medication. During this description the physician may want to pull up the same X-ray image on his hand-held to explain the situation to the patient. The context system recognizes that the diagnosis is complete and that this is a patient education/explanation request so downsizes the resolution of the image to fit the hand-held. (this couldn't be done during the diagnosis phase since the image quality would not allow for a quality diagnosis). Nortel Confidential 200 of 226 The physician then enters a pharmacy order for a pain killer drug to be administered. The system validates the order (source, patient, access privileges...) and passes it to the pharmacy order system. The pharmacy order system checks the order against other prescribed medication for this patient in the Current Event Record, finds no contra-indications for the requested drug, and then interrogates pharmaceutical section of EHR
finds no drug allergies but does find a long term and currently standing prescription for a drug for which co-prescription of our physician's drug choice is indeed contra-indicated.
Hence the pharmacy order system has detected a conflict - the patient is already on a drug for which the currently prescribed drug is contra-indicated, and it advises the physician of drug conflict. A basic message (NACK for prescription validity, ACK for reception of request) is sent back to physician via the PoC system along with a list of suggested alternatives. The physician either picks one of these or inputs another alternative (or can override the contraindication if he feels that the balance of risks warrants this action). In this case the clinician accepts one of the alternatives proposed. The PoC
system transmits physician request to pharmacy database which repeats the validation processes, this time successfully. The physician receives a confirmation that the order has been received at the pharmacy and at the local nursing station.

This Physician-patient interaction for this encounter is finished, so the physician leaves for next patient - keeping the terminal with him - thereby maintaining his authentication ready for the next encounter. The increasing separation between the clinician and the patient initially terminates preferential routing of that patients data to that clinician and, on approach to another patient, sets up the same functions for that patient.

The drug order placed by the physician before leaving the patient goes to the nursing station and the pharmacy. The physician who issues the prescription and nurse who will eventually administer the drug never see each other. The pharmacy system (drug stock location and status system) and the patient location system cooperate to confirm that the drug is either held locally at the Nurses Station and that the Nurses Station has an adequate stock or has to be sent from the pharmacy. In this scenario case the drug has to be sent from the pharmacy to the nurses' station. The pharmacy dispenses the drug into a bar coded or location and ID tagged container which uniquely identifies the drug dosage as being for Patient "X" in room "Y" for administration at time "Z". (Note in a fully bar-coded system with medication bar-coding the stock at the Nurse's Station would have to be bar-coded).

An administration order is sent to the Nurses Station complete with a priority, urgency flag. The nurse on duty has to acknowledge receipt of order which is messaged back and a nurse has to administer the drug when it arrives at the nurses' station.
When the drug arrives at the nurses' station its presence there is detected and, since the drug administration is urgent, a flag to administer the drug is sent to one of the on-shift nurses, based upon the context of their location and current task level as well as their authorization and skill in administering the procedure (in this case a simple drug administration which any of the nurses could do). The administrating nurse takes the drug to the patient and administers it. This is accomplished in a closed loop system that confirms the identity of the drug dose, of the patient and of the administering nurse as Nortel Confidential 201 of 226 well as the time of administration. If all of these are correct the drug administration supervising system will confirm that the drug can be administered to the patient and the nurse then proceeds. A lot of transaction complexity is hidden from the Healthcare professional allowing them to get on with their high value work but receiving enough information back to ensure that the system is responsive to their orders.
Figure 16-4 -Figure 16-7 show information flows at various stages of the scenario outlined above.

- -------------- ----- --- -Environmental sensors - heat, I ht, su stance Environment Rad ' detection, RF-ID readers at choke points, etc, an d Context archive o 0 0 pqcs PACS
Location, ID primitives network eNers 1 2 3 n st rage System Common --------- ------------ System for POG System ---- mulhple RIS Term Term Terrn Tenn CPOE t 2 3 n modalit~ies CPOE ------ ------- -------------- -----------------terminal Etc. Gateway/
, ~ `=. Firewall ----- ------------------------------ ----- Diet 7 Wireless POC sub-system Scheduling DepartmenU
W-A h C H I S Pharmacy Functionalit 8o2.ti ess Cardiology vS stems I, .,~.=,a=.. .... ..., tem Billing Gateway/
~'------------------------------ --------- Firewall Laboratorie Local Mod Mod Mod , = --.
-'----------------------------------------~ EHR 1 Wireless Secure AAA
Physician identification and personal attributes, access profile Terminal type identification and emulation ___..
.......
1. Physician enters patient room. The patient is complaining of extreme pain.
= Continuity of authentication thru proximity is tracked, even through AP
changes or changes between various wired, wireless systems = Network recognizes hand-held type, user ID, sets up appropriate associations Figure 16-4 Walkthrough on Hospital System - with ECAS - 1 Nortel Confidential 202 of 226 Environmental sensors heat, light, sUbstance I Environment de Rad tecUon, RF-ID readers at chok"oints_-,_etc and Conte7d archivei o 0 0 o PACS
PACS
Location, ID primitives network Servers 1 2 3 LJst rage System -- - Common --------------` --------------- POC System -----,. I multp~lefor R S Term Term Term Term g 1 2 3 n modaliLs CPOE õCPOE ---------------------------- - ------- ------terminal Serv r ~>l t EtC. Gateway/
Firewall / Diet ,---------------------------------------------Wireless POC sub-system w-Sec cheduling De artment/
-Atta ~( K w-Aut O HIS Pharmacy unct~
_~ ec! Ic Cardiology S sy tems s~m !? _. Billing ewa wally!
r ----------------------------------------- Fiae I Laboratories Local EHR Mod Mod Mod 1 2 n Physician info request Confirmation of match - physician-patient Information delivered 2. Physician calls up chart on a wireless tablet/PDA .
= Physician secure access is confirmed - continuous proximate authentication.
= Physician is authorized to access only a specific set of patients and specific sets of data.
Figure 16-5 Walkthrough on Hospital System - With ECAS- 2 --------- Enwronmental sensors heat light, substance ---- ------------ -------------------------deteeton RF ID readers at choke oints, etc. EnHronment Rad p and Context rchive/ o 0 0 o PACS PACS
Location, ID primitives network ervers 1? 3 Pp~ Storage System Common POC System --- System for multple CPOE Rl' ' Term Term Term Term m : r F li w.H.~ 1 2 3 n mad ~ ahtes r ---------------------------------- -----------------termmal ~ 3F rEe-Illl ~
1 Gateway/
"= ~~L ~; '` Firewall ---------5-- ------------- -- Diet Wrreless POC sub system w- ec Scheduling 1Atta De artment/
0 Pharmacy unc lona It -~ HIS eci s stem Cardiology vS stems IlAN" - , ; Billing Gateway/
Firewall 4 Laboratorie Local Mod Mod Mod 1 2 n Image requested~ notification of need for larger screen e rvere Request for nearest big screen display Advise physician of location Detect physician, terminal at location, redirect image to queue on display Physician books surgery 3. Physician calls up the x-ray on the laptop, but the resolution is not enough. System locates the nearest high resolution radiology display, which is down the hall.
Location and availability of radiology display is transmitted to the tablet.
The application session is continuous as the physician walks down the hall;
the image is queued and waiting.
_.. Physieian. confirms fradure, books theatre-time for surgical realignment later that day _.. _ _...._..._ Figure 16-6 Walkthrough on Hospital System - With ECAS - 3 Nortel Confidential 203 of 226 ---[Environmental sensors - heat, ii ht, substance detection RF-ID readers at chok6 oints, etc. Environment Rad p and Context arch vei o 0 o Pacs PACS
Location, tD primitives network ers 1 2 3 n st raga Sysmem ystm or POG System m---ul- hle RIS Tenn Term Tenn Term imag g CPOE t~ t? t 2 3 n modahties n--terminal Gateway/
= ti Firewall - ------------------------------------------- ' Diet .
Wireless POC sub-system Scheduling DepartmenV
Atta 1\\\ w Autr - r OC Pharmacy Functional -I:ces ~ct tc yS stem JEstem5 N ~ Gateway/
Firewall ~Laboratories -=
Local Mod EHR Mod 1 Mod 2 n -'- -------- ------- ----Authenticat~
ed Physician and terminal proximity track, authentication maintained Order4 Pharmacy Pharmaceutical database detects problem, alerts physician Revised order sent 4. Physician returns, prescribes painkiller, but the system sees the patient is already on another drug for which this painkiller is contraindicated so the order is changed to an alternative painkiller.
= The drug history of the patient and pharmaceutical database are queried.
Altematives are suggested by the system.
> Steps 5-8 continue this process, involving the nurse, medication bar-code &
tracking drug administration ......... ......_......_..._ Figure 16-7 Walkthrough on Hospital System - With ECAS - 4 Figure 16-8 shows the interactions that are pertinent around the PoC
communications application during this example.
.............
............_......_..........
_..... ----- --.._ __._ HIS HCIS Hospital Clinical, . tient Patient Facilitv, Staff and Facility Clinicia4-data data ta Clinica) data Patient databases ..... ......................:........ _...... ;,..:.....; and infrastructure .. ..... . .. . ... .. ...........................
R5 - Clinician Point of Care Clinical services communications R7 - Drug safety, security and :...................... ................:
environment R4 - Equip't/ clinician, clinician/ Location-proximity patient or equip't/ patient association based association and sensor association Ri -Clinician R2 - Patient R3 - Equipment Basic sensor Basic coordinates location tracking and/or tracking, location iayer and Environmental and context monitoring and condition structures Awareness Figure 16-8 Scenario Interdependencies For Point of Care Communications Nortel Confidential 204 of 226 16.4 Application #3 El-Code Blue/Pink - emergency cardiac/
respiratory event - adult/pediatric This is an emergency response to an unexpected life-threatening cardiac or pulmonary event and has three key phases, two of which are conducted under emergency conditions and the third of which is hopefully a more routine environment. The three phases are: -a) Code Blue triggering and response team formation with resources at the event site b) Code Blue team clinical interaction with the subject patient c) Post stabilization treatment This section of this document will only deal with the first phase because the second phase is primarily a very intense form of a Point of care encounter albeit with a large number of clinicians and collaboration activity. The third phase hopefully is a routine series of treatments which from our perspective are centered around various routine processes outlined earlier in this document, including PoC sessions and clinical collaboration sessions.

In addition ECAS can make a substantial difference in how Code Blue teams are assembled and how rapidly they can be assembled.

Before we examine the contributions from ECAS we will look at the objectives of the team-forming phase of the Code Blue response. The fundamental objectives are: -b) To identify appropriate personnel to join a code team at the event site c) To form an appropriate "code" clinical response team rapidly from the available clinical resources and to direct them to the event site d) To provide immediate notification to proximate clinicians, and to code team/resuscitation team members for purpose of assessing, stabilizing and saving the patient e) To identify appropriate functional available nearby equipment necessary for the team functioning and trigger its rapid delivery to the event site f) To notify all team members of the location and nature of the event g) To avoid any more disruption of normal hospital routine than is absolutely necessary commensurate with meeting the objectives listed above The key attributes of a Code Blue team formation were given earlier in Section 15.2 16.4.1 Code Blue (El) - Qualitative & Quantitative Requirements The Code Blue event can occur anywhere within the hospital building or campus.
The hospital may have 100's or 1,000's of patients but usually only one or a few involved in a Code Blue incident at any one time. The hospital may have hundreds or thousands of staff, of which a significant subset are on duty at any one time - but ideally only the nearest available appropriately qualified staff should be involved in the Code Blue Nortel Confidential 205 of 226 incident to speed up the team formation. This requires the team-forming algorithm for the Code Blue context manager to take into account parameters and data-points such as: -a) Event location b) Event sub-type (nature of emergency) c) Required skill set or training requirements to respond to event type d) Identification of members current shift of clinical staff e) Assessment of skills, training of members of current clinical shift f) Location of members of clinical staff relative to event location g) Assessment of current staff activities - are they interruptible From this the Code Blue team assembly algorithm will attempt to identify the best fit of nearby staff with the right skills set who are interruptible, based on their current tasks (obviously a brain surgeon in the middle of brain surgery is not likely to be interruptible and may not have the skill set for cardiac resuscitation). The identified individuals should be directly and discreetly contacted and requested to acknowledge that they are on their way. In the event that an individual has to decline the algorithm needs to have already identified a back up.

While the team members are en route to the event site the Code Blue controller can push data to them about the situation.

In parallel with the team formation the Code Blue equipment algorithm needs to locate and validate the fitness for use of the appropriate equipment, likely a "crash cart" which are notorious for "wandering" in hospitals, and to dispatch someone to get it.

Nortel Confidential 206 of 226 Patient experiences LTE

First responder raises alarm First clinician declares "Code Blue" on terminal Clinician, patient ID, location determined by Code team skill ECAS Clinician 1 list requirements skills ~= List of candidate Blue team clinicians established Duty roster Clinician location from Each class of physicians ECAS location rank-orden:d by proximity Clinicians contacted Clinician accepts Clinician declines/
does not respond Add to team, notify of location Is there another clinician with Is team complete? theselskills Yes Yes No As per POC example + Go to that clinician Contingency plan (may equipment location example include re-contacting (for crash cart) clinicians) Figure 16-9 (E1) Code Blue team formation phase waikthrough Figure 16-9 shows a possible team formation activity following a patient experiencing a Life Threatening Event (LTE) such as a cardiac arrest. The first responder notices the event and raises the alarm. In this context the first responder may be a clinician, a patient relative or other visitor, any member of the hospital staff or may be a piece of medical monitoring equipment. The monitoring equipment or first clinician to arrive on the scene determines that an event has occurred that requires a "Code Blue" response and declares a "code Blue" - this can be done automatically by the monitoring equipment or by the Clinician entering an appropriate input into the HCIS via his or her hand-held terminal, a Code Alarm button or any other method. This will cause the ECAS system to activate its Code Blue protocol. Assuming that the trigger was a clinician entering an alann code into their hand-held device at the patient site the first step is to determine the clinician's identity, the identity of the proximate patient and the location of the Code Blue event patient location). The clinician may or may not be allowed to enter in a sub-code to enter the nature of the Code Blue (e.g. Cardiac arrest versus major stroke) or this may be left as generic - LTE recovery required. The ECAS system accesses the HIS clinician skills database and assembles a list of appropriately skilled/qualified clinicians (this may have been done ahead of time as a background task) capable of responding to a Code Blue event. It does this by comparing the pre-defined list of requirements for a Code Blue response team (which may vary from hospital to hospital or even department to department - for instance the requirements in a general hospital ward may be different to Nortel Confidential 207 of 226 those in a geriatric ward) with the clinician skills list. The list of appropriately skilled clinicians is then run against the duty roster for the hospital for the time of the Code Blue to determine a list of appropriately skilled clinicians who should be "on shift". This generates a list of clinicians with the appropriate skills who are supposed to be present in the hospital. But these clinicians could be anywhere in the hospital and clinicians who are at the far end of the hospital have a much longer travel time to the Code Blue site than do nearby clinicians. So the ECAS system consults its clinician location and tracking application and compares the clinician locations for the clinicians on its Code Blue Candidates list versus the code Blue event location, computes travel time or distance and rank orders the clinicians in each class of available skills set, the ranking being from nearest to furthest. It then contacts the nearest clinicians with the required skill set. If the clinician accepts then the clinician is added to the Code Blue team and the skill requirement is decremented off of the Required Skills list. If the clinician is forced to decline (they may be handling another emergency) or doesn't respond within a very short period of time, say 5 seconds, then the ECAS system contacts the next clinician in that skills group and this process continues until the Code Blue team requirements are met or if they are not met once all the clinicians have been contacted then a contingency plan is activated.

Since the urgency of response is key here - seconds matter - the process that has been presented here as a serial process may in fact be largely implemented by background pre-processing in anticipation of the Code blue event (for instance keeping an updated list of on site Code Blue skilled clinicians rather than generating it in response to the Code call itself) combined with parallel processing and communication. For instance instead of serially contacting clinicians all appropriately skilled clinicians within 150 feet of the Code Blue or on the same floor as the Code blue may be contacted, followed by contacting all the clinicians within 300 feet or within two floors of the Code Blue on the grounds that a clinician can run up two floors (but not 15) quickly.

Another part of the Code Blue assembly operation, one not shown in Error!
Reference source not found., would be to locate the nearest available (not in use on another patient) and functional Patient resuscitation Cart, usually known as the "Crash cart", and to dispatch an orderly or clinician uninvolved in the clinical aspects of the Code Blue to go get it.

It is envisaged that, with significant refinement form this first crude description, a approach such as this will allow the formation of a Code blue team more rapidly and optimally and with less disruption of hospital operations than current approaches.

Once the Code Blue team is assembled the clinical processes of resuscitation and patient treatment become, from an ECAS perspective, an urgent and critical Point of care and clinician Collaboration activity.
Figure 16-10 shows the interdependencies for the overall Code Blue event. The team forming portion of the event uses the HIS facility data, clinician data and HCIS patient data modules along with the clinician location, patient location and clinician/patient association modules.

Nortel Confidential 208 of 226 -----------------------------------_--HIS--------- ~HCIS
spital Clinical, - Facility Clinician L Patient Patient Fcilitv. Staff and data data data Clinical data HPtientdatabases Hfje ...............................
?:................................................... :
R6 - Clinical E1 - Code Bluelpink - emergency collaboration cardiac/respiratory event - adultlpediatric Clinical services . ..... ........ ........... = R5 - Clinician Point of Care R7 - Drug safety, communications security and ......................... .
......................................................
environment LL_ R4- Equip't/ clinician, clinicianl Location-proximity patient or equip't/ patient association based association and sensor association RI - Clinician R2 - Patient R3 - Equipment Basic sensor Basic coordinates location tracking and/or tracking, location layer and Environmental and d context monitoring and condition stfuctures Awareness Figure 16-10 Scenario Interdependencies For Code Blue 16.5 Detailed Requirements from Drill Down The first view of quantitative requirements for these three detail service scenarios are given in Table 16-2 Quantitative Requirements Comparison Nortel Confidential 209 of 226 Equipment trackfna. Clinician Point of Care Code$lue (El) - team Code Adam (E2) -ocation and condition (R2) Communications (R5) forming phase Geography Campus in-building, one or a Campus Campus in-building, one Campus few buildings or a few buildings + 250 yards outdoors Scale 100's - 10,000's, 100's to 1000's, 100's or patients, 100's of pafients, 1000's per floor, 100's per floor, Combination of R2 and combination of 100's per AP 10's per AP R5 R2 and R5 Location precision Room, 3m Proximity or 20 cm Room, 3m Proximity or Room Room, outdoor for advanced application 20 cm for advanced app's coverage Other sensors On medical equipment No No (biohazards??) No (heat??) Volume of data Kb/s M b/s Kb/s Kb/s Message Latency Second Sub-second for theft Seconds (user Sub-seconds Seconds applications satisfaction driven) App Availability** Medium - 0.99 to high 0.999 High - 0.999 Very high - 0.9999 High - 0.999 Frequency Routine-hundreds a day Routine - continual 200 per year for 400 Rare-less than 1 usage bed tertiary care per year hospital Criticality Moderate (for efficiency) Moderate (for efficiency) Mission-critical High Mobile devices Tag Phone with graphic Phone with graphic Phone with display, Tables, PDA's display. Tables, PDA's graphic display for EHR
Privacy Minimal, For patient data in High Minimal- during incident Minimal-during monitoring apps incident Security (of Medium High Medium Low (due to application access) mdtY) Auditing, logging Yes Yes - Efficiency, Yes-detaited (?) Yes (ifYequired) malpractice Hospital may not want Mobile Device 6 months minimum (Tags) 1 day (shift plus personal 1 shift 1 shift Battery time when on call) 6months min (Tags) 6 months min (tags) 6 mo min (tags) Data Location - periodic pings Voice Voice / Audio Voice / Audio Characteristics Condition - low data rate Text, Image Text Text messages Video - collaborative, Location Location Operational data - graphic or diagnostic web pages, low res video Web pages, e.g. EHR
such as EKG Location Web pages Data Rate Kb/s Mb/s Kb/s Kb/s Privacy Minimal, For patient data in High Minimal- during incident Minimal-during monitoring apps incident " Initial view - stringent requirement to meet- may need trade-offs ~- .. . i Most stringent requirement Table 16-2 Quantitative Requirements Comparison Nortel Confidential 210 of 226 17 Appendix 2 Numerical Strawman And Reference Hospital Model This section provides a hospital model and applied it for the use case example of emergency code call responses. The model can be used for other ECAS
applications as well. The approach will be to:

1) Model a hospital a. Layout of the hospital, identifying key departments b. Coarse description of staffing levels, schedule c. Percent of time a staff member is likely to be in an area 2) Describe a prototype response for one application set, emergency code calls a. Roles called to the scene of the incident b. Rules defining particular respondents (e.g. location of a doctor) c. What are the secondary responses (e.g. what other staff members are notified, or "Call Fire Department) 17.1 Hospital Model Antelope Valley Hospital ( http://www.avhospital.or /) has been chosen as an approximate model for this exercise for several reasons:

1) It is a medium-to-large size hospital where scales issues with code calls may arise, for example not knowing who is on shift or in the area.
2) It offers a wide range of services.
3) Sufficient information - we had previously research several hospitals, and this one had the most publicly available information including layout and staff levels.
A downside is that a competitor (Cisco) owns the wireless infrastructure.
However, that is not relevant for this exercise and the model will be abstracted rather than identical.
The abstracted hospital, Hospital X, will has state-of-the art communications, sensor, and IT technology that provide multiple information inputs that may help to enact a Code Call.
Hospital X has a wireless communications system (e.g. WLAN phones, PDAs, and tablets) that allow paging, voice communications, and the communications of data such as location data to selected groups.
17.1.1 Staff Aftributes Key attributes of the hospital staff:

- 1800 total (professional, technical, service) - 350 medical staff (doctors, nurses) - 380 beds Nortel Confidential 211 of 226 Given that California has legislated a minimum nurse-to-patient ration of 1:5 (-76 nurses per shift at full capacity) and a nurse can work a maximum 40 hours week, an estimate is that 80% (-300) of medical staff are nurses and 20% (-50) doctors or residents. In addition, doctors in private practice or specialties may be associated with the hospital.
An ad hoc estimate of more fine grained staff distribution is shown in Figure 17-1. Note only ad hoc verification of the data was done via conversations with few medical professionals, and needs further research to increase the accuracy of the estimates..
Another statisticl is one resident on call (in the hospital, all the time) for every 50 patients.
One would expect zones like the ICU, Obstetrics, and Emergency would always have a staff doctor on the ward during regular hours and always have a resident in the hospital responsible for each of those particular areas.

Doctors Emer enc Room Doctor 15%
Doctor 40% 20 Residents 10% 5 Emer enc Room Doctor 10% 5 Surgeon 20% 10 Anesthetist 5% 3 100% 50 Nurses Tria e(ER) Nurse 10% 30 Ward Nurse 75% 225 Operating Theatre Nurse 15% 45 100% 300 Support Staff Laboratory Technician 10% 155 Clinical En ineerin 5% 78 Orderlies 20% 310 Security 10% 155 Admin 10% 155 Maintenance / Facilites 30% 465 Other 20% 310 105% 1550 Figure 17-1 Staff distribution (ad hoc estimate) 17.1.2 Staff Time Distribution All work 40 hours per week 100% staff level during day, 20% at night - Nurse, orderly day 6:00 a.m. to 8:00 p.m.) - Doctor, surgeon, anesthetist day 8:00 a.m. to 9:00 p.m.
Nurse -10% on phone/comms, 15% admin, 15% breaks, 50% patient care, 10% non-interruptible patient care (e.g. surgery assist) Nortel Confidential 212 of 226 Anaesthetist -10% on the phone/comms, 15% admin, 15% break, 30% preparation, 20% patient care, 10% non-interruptible patient care Surgeon -10% on the phone/comms, 10% break, 20% consults, 20% preparation, 40% non-interruptible patient care (surgery) Porter (Orderly) 10% on the phone/coms, 10% admin, 15% break, 55% patient care, 10% non-interruptible patient care Doctor 10% on the phone/coms, 10% break, 40% patient care (consults, rounds), 20% non-interruptible patient care (treatments) Emergency Physician 10% on the phone/coms, 10% break, 40% patient care, 20% non-interruptible patient care 17.2 Layout The campus is shown in Figure 17-2 and the main hospital building in Figure 17-3.
Figure 17-4 shows a physical abstraction of the functional areas of the hospital with the approximate size of the functional areas outlined and Figure 17-5 gives the approximate square footage involved.

Figure 17-2 Antelope Valley hospital campus.

Nortel Confidential 213 of 226 Square Footage Floor Area (1000s) Notes Floor 1 Admin & General 61 Administration, Admitting, Cafeteria, Conference Rooms Emergency 37 Lab 16 Phamarcy 13 Physio 21 Floor 2 Mental Health 3 Outpatient Care 14 Progressive Care 20 Critical Care 7 Respiratory 10 Includes, storage, patient prep, admin, theater (80% of Surgery general 9 Surgery area) Surgery - operating 2 Theatre & surgeon prep (20% of Surgery area) Floor 3 Women's Center 22 Labor & Delivery 16 Continuting Care Nursery Neonatal ICU 6 Pediatrics 9 Pediatric ICU 9 Includes, storage, patient prep, admin, theater (80% of Surgery - general 10 Surgery area) Surgery - operating 2 Theatre & surgeon prep (20% of Surgery area) Includes, storage, patient prep, admin, theater (80% of Tower 4 Surgery - general 20 Surgery area) Surgery - operating 5 Theatre & surgeon prep (20% of Surgery area) Includes, storage, patient prep, admin, theater (80% of Tower 5 Surgery - general 2 Surgery area) Surge - operating 5 Theatre & surgeon prep (20% of Surgery area) ampus Figure 17-5 Hospital zones square footage.

17.2.1 Physician Specialties The following is a partial list of physician specialties that are relevant for workflow applications:

1) cardiology 2) dermatology 3) gynaecology 4) neurology Nortel Confidential 216 of 226 5) obstetrics 6) oncology 7) orthopedics 8) otolaryngology 9) paediatrics 10) proctology 11) radiology 12) trauma 1) general surgery 2) thoracic surgery 3) neurosurgery 4) circulatory medicine 5) general practice 17.2.2 Staff Availability versus Location The following is an example list of staff availability versus location.
`Conditional' means that a staff member is available under certain conditions, for example in an emergency situation.

Offsite unavailable OR unavailable Ward conditional ER conditional Washroom conditional Radiology conditional Breakroom available Lobby available Office available Laboratory available Administration available Lunchroom available 17.3 Hospital Model Applied to Code Call Scenario A model for a hospital emergency code-call system will be described, including example sizing parameters, rules, and process for an automated code-call assistant system in a hospital, for example a "Code Blue". As described in Section 7.2.1.1, a "Code Blue"
indicates a cardiac arrest, and currently is accomplished via broadcast overhead paging.
The response to the Code Call usually include the fonnation of an emergency team that responds to the site of the incident, as well as ancillary responses to other personal in the hospital and in some cases external agencies. By including modem wireless communications capabilities and processing information inputs such as location, schedule, Nortel Confidential 217 of 226 and communications status, and incorporating sets of rules, this process can be much improved. For example, only the closest nurses should be called to the scene via their mobile communications devices rather than broadcasts to an entire ward or hospital. A
view of the system model is shown in Figure 17-6. The system must operate reliably and intuitively (i.e. a human-like decision in the event of incomplete information or errors).
The rules interpret the input information to define the context of the code call scenario.

Event Code Call I = Warà 1v prccess?i Inputs (Real-time) .......................................
= People & eqLlipme+it context attrihutes = Location ---^Ranuorn walks Piased on shiY sohecluis, System aGtiotls~
equipmert iast know ioc.atior: ~ tauildirg ,' ':Ca?P' team vdarrl cons<ra;rtts =Context_ Ski)1 appropriate Coarse (1?hysician, r,urse) ]ocal or mobile Expert icardiologist) = Shift Schedule =Rny devÃce = Gcmmunications Presence = Locate equip niennt = Push iliformation = Enar-t Qther emergency systems and protocols Figure 17-6 Code call system model.

17.3.1 Information Required for Code Call System The following information will generally be available to the Code Call system.
However, the system must also be able to perform without any information except the code type.
Code Call 1) Type of call 2) Location of calling device (mobile device e.g. WLAN phone or fixed push-button) People 1) Role 2) Home base for role- e.g. Ward A, or Floor A, or roaming 3) Schedule - on shift of not 4) Communications presence - in a communications session (i.e. on the phone) or not 5) Location - room Equipment 2) Type 3) Home base for role- e.g. Ward A, or Floor A, or roaming 4) In use or not Nortel Confidential 218 of 226 5) Location 17.3.2 Number of Code Calls Per reference [2], for a 400 bed hospital there were 543 Code Blue calls from Jan. 1999 to Oct. 2004, a 70 month period, or approximately 93 per year.

The following is an ad hoc estimate the distribution of other code calls.
CODE CALL DISTRIBUTION
Ad hoc estimate for a 400 bed hospital.
Calls per Calls per year 10 years %
e 2.00 20.00 1.23% 1ire (including a se a arams am 0.10 1.00 0.06% Infant/Child Abduction ray 0.30 3.00 0.18% evere Weather Orange 0.10 1.00 0.06 /a Hazardous Material pi e ease ue 93.00 930.00 57.11% e ica mergency - u t Pink 47.00 470.00 28.86% Medical Emergency - Pediatric (Includes non-breathing new borns) Yellow 0.30 3.00 0.18% isaster Violet 10.00 100.00 6.14% w ent atien om ative ilver 0.05 0.50 0.03% erson with Weapon/Hostage Situation rown o issi Figure 17-7 Code call distribution (ad hoc estimate).

Nortel Confidential 219 of 226 N
N

N
~
(~ t =1.~

O O

=~ o O v~
U
N :~,, CL
W
Q co CO oo r-4 ts! y o a~ CZ o y ~ o v -a 2 O v 73 tn c v _ c ~.+ v r- y >a L[i] ~ r. y C-p CJ O X N ~ ' ~ y ri y y N r .n C.~ U
y0y rC'r r- C_ G y 73._ = cC O d' M1 Q C, L Q L+ --,:, U CCS y r n y= r y[L.
to C.) ~ .E >
~ `) y /) +--~i--~ V] C~S , J . L L L C (y ~~~',~' L
y~,~ ~ Q f V) .~ ca y rr-õ fl.. _' J L C~ ~ Q 2=~.~..' y) ~O
U N O L L y ~l +- n c G s ->_ Y-- G v r n _ :n 7= J

7:; L ~ ~ '-G' = 2 ~ G` 5 ~ = i- . - ~
ac ca = U=~n ~ =>, c3 J .~ ~q U O W O- y c`~s -' ~y L 'o G ~ 'r ~ c3 "~U U v = n ,O LLJ
=
a y r*^ tn G 'B U ^n y > > bn .~. p C',5 m V~ y CC = ^ y L V] ~, hif) .~' y Y ~ . _ > -n i p y _ ~
- J ~ ,~ ' ry y ~ v - ;n u C = G v: >, v ;n = cs cl~
G L - ~, o J L - -~
a ~ y G O p _ ~ . _ J ~) ^ y ~ y si a y-_ ~^
v = y 2- ~ ~ C = y O 'B ~ ^.
-- U y ca cz 2 CC 5 OU

y 2 cz~ /~ -n ~, :7 _ y >> . J
bn N J r O O ~ _ L ~ ==--= = ~= ~c '_' - C ~ ~
% o G
~ Q > - 4 > .`^' ,0.= 'n j = ~ .~_. ~ ~
. L y ~ ~ ;i, - p `~ i /~ - y ~ L c*-, y = G j ' - ~ y ~ y=^.- N c=~ y-. .~ '" +n- Y.~ ~ cC ^,~ õ C r v: > J ~ v~ O
O ;f o L ~ s ~' ,. v G ~ v õ~ L. ..n L Y v v .. rn >
= X y J =n ~= s tf) ~ y== J y_' >
_= ~ a y o = 7 c m y -7:; E -z; c G
y y J ~J cd C.-~ Cn j,`~ n~ y'L 1~ V? ^ 7J , ~ y U' J'~ G-p '- C' y T ' ^J ",3 U ^ c~ . . y - = '.O ..G v, - Z f r- ~ r ~ ~-= r ~ :J
= o r~ ~' Q U ~j -75 C::::
0 0 G o 0 0 - p Z U CD =- Q ^ _ o - ~ o > = ~ F. .~ u o ~ ~ _ s c- 5 o n U _ v ~
y `u u v ' v > ^
o =n n - n r cQ ; ^
v= tn , c-, 17 y n ~ - = o - = y = a ~
cz o ~ y A `=~ _ 07 :~ _- v y ~ :a c3 ~. "B
o = C73 = _ G y y _ -a J
> 0 0.~ o~s y a c C~ ~ pi m v a Z~~ cs m `
LIIIItii ct a; C~3 V C13 ~
ct cl o~cz (Ij ct-c "o cJ o c~i o~~ 3 o ¾ c_ c L' ~ ' o n E c o E o = q ai c c " en C13 cr o o .~ N o a ti ~ o a U = o ~
Q 0 ~m~ a~ W v -~ o a> o o N
Q fl..~

U "O M

N N

a. N E tA tb C) >, =+_' 4.,, C `n O ~ ~ O
L cz ct N O N "O
N O C'5 Vs (L)-S- C,3 T 'O fl Y N

i' O -~~ C1. 'a N y cC a' ^V^,0 v~ -..7 cLC
.D
c~ ~'~ W U~ fYa C U
M N V] C1., L V] N _ Cd U C _ = ~ O .f. >~ 0.. ~}N''~ ~ ~ ..O C/~ L Cd V1 'a ~>l 'C3 N('! O ~ O = [n L'LL CI..OD C N C~ 3 O Cn V] L Y C y L C
~ Q W ~ U a~ c o O~ ~c~ U

Z
~ a o c _ c v .
-' y cz a) a n 4~ ca Q) 0. ' C13 -U u cz ~, o s u acs U-a ai o v~ ~
N U O
_ L ~ O C
v as > c > > - U ~ L c u = ~
U O U cd CJ dJ ~j 'bp O U = N N ~ ~ N .0 O II
' ~
r. N O ~ N CO U O
N CC v~ ' C U N s.. N U O
T =~ ~ ~ ~ ~ ~ ~ L ~ ~ L U
N t)b b-0 v~ O U N bA .aZ -p ~--' CG O L a b-0 .a O
~+p 3 = U ' n N = L U _= _ ' ~ ~ ~ cc C s.~.= ~ y"U' ~ ~
CA N L'13 O ~ Cz. ~ = C~5 ~--+ ~
t > o . CZ x = ` 75 n B ~ rL~n ~ rn c >u ,.~ a ~ =
~
O' L~ N~ ~ U s. L O j~
L' a " o a v~ ~ " c = ' cd a) _C13 U a~i ~ C~3 ~ ~ cd c,3 i a _ o U ~L a ~s a w ~ ~ ~ = _ ^ ~ ~N ~ U
N = rn ^ ~C 'D = ~ i L? a a ~ 0 Q o ' c N i ~
. .o c > ~ fl c w E
~ p a~ .~' a> U R. U, oi pcz~ a) Op c3 E
d~~ 2 `. Q C~ J E
ti th cr cd '- [] M Y N G v~ a, cC N O cC r ~
O y U + p y O a C ~ 1+, ~ a o n Q Q) >
c.) E aci o ~ ~ > o c ~C
G p ~ a~ ~ ~ o = c ~ ~ ~ -o > ' u,,, ~ ~ ~ ~ '~ ~
~.+" O G' U N ~ +-= ~
"a v~ a~ ^o L = ~ O . c~ ~~,' >C ~ ~ ^
ct = = = C "Z W
ami ' c ~ ct v) V~ cn s L~ U a~ U Q d o 3. Q 3 sa Z~~~
~

~ ~ -W o o o U U U

N. U 4=, Y 7~ U p w= cd U U r.., E u) o o s s_ = 0 3 /~ ~
C13`l ~
-z a? a) u o s p s= CZ ai o a~i api a a ~= a a~ = o= a~ Y=
cz a~ L w a~ O S"C3 ? L ~:-p cC
=~ U C~ a> ~ S
c c,3 r..' ~ y`~ Y'6 = N YO N M = Cn Y
L . L Y =
cG Q Q U ^ a) _ ~'3 cd a3 U
p L \ = = L = y [~] ~""i c') C,3 s u = -a a) N =V O N V p cUi~ .~ bp~ O =
_ _ cd = p = _ U
_ "'~ y~ = U w = L O Q.Y ~ ._ = V]
D p U ca~~ (U a) 'O N 73 mQ p= c~ = N
L.C. O~ C~ V] w~/ Y~~ Qn Y L U O.~ CC N
Q
U U ~
cz v a~i v~~ s a=i ~ N
.~o ) s o E 2 a~ v -o -n ~
E ~' O O _' cC N cC ~~~
L N = L = == U ^ y..Y = L' c C) cu m t tti~so 7E
Y L L O RS N
3 ' v~ = a U y L a~ w o p s p -o N p '0 C~5 a3 4-0- = ¾ S U U ~ 7 0 CZ Cn . = CZL, cj ,--1 CO Rj E (L~ 2 = _ p 3~ op ~= a~ a) ~ a) ar-~~
N'~ >~ L CC =Cd T~' f O a~ ~ Y V) U a~ . L~l~~' Vl O Q. 'D = y CC U
aj cz.~ c~ w 7 Q

. L y s o ~a ~ ~ `~ o = a~
Y o Y = w ~~ O
Q CC t)b>, Y L U~1-L- N U X=(, ~ ~.a eY-~ ~. V-py 0 cj -'~p Wp- c~ N s o +--~.
=N
-ID
L-n p~ U- U U U ~'~ ~ U U pU Y Y U~ p y U N

0 L~ r3 p iy ~ L fl.. -c. Y U S"' ~ L ~ U ~1.' L
N vD O=`~ `~ p_ O cC
(C U.~ U =
ca. +-' U c~ s" W = rn Y'_ _= v~ O`n O c= 2 ~.Y cG' wO
O
~" V] o U ~ (} E ~ ~ = N S-. u (y d -b Y V~ = = N
~ U U C/~ ..~ Q~ V] Q= Cd L v~ p s cd ,"N p O-B = p v~
(~] C~ 'S1+ U L.. S'r L Y" S'r N'O L~=~ = O
O U I I I I ~ Y~ Y O L O O Q, ~ cC

.L7 vUi U
p ~,7 O cC = c~ ~ = S3= = y cd L1. ' = N O
z._ 't s 3 n. o n. ca= O ~ 0. o m a o 3 , "o Z N
I
O cz .~ `t C13 p O O
'6 n-t 4-;
0 o bA~ N ~=- 9..

'~p _ ¾=
0.~. ~.D 3 O. Q~~ 4~
s c ~

~ J
d ~
U U

18.2 Emergency Codes and Protocols for Duke Memorial Dukes Mernorial Hospital Peru, Indiana Emergency Code Designations __---- -__ __._ - _ Code Name Emergency_ Who Resprrnds Student Respanse CodeI Cardiac/Resp. Dr., Resp. Therapy, Your Pt. - call the code, begin Arrest ENfT`s designated CPR
nursing staff.õ t?ther Pt reportto Instructor Code ,..,,.2 Delivery, no Dr. Dr., Resp.'1'herapy, No response needed 08 nurses Code 3 Tornado Watch AEI employees. Close drapes in Pt. rooms, remove items from window sill, move Pt. away from window.
Prepare to move them to the halfwaY. ...
Code 4 Tornado L'Varning Ali employees. Move Pt. & visitors to the Code 40 Bomb Threat All employees Check for unusual packagesJ
containers Code 99 Immediate help All employees No response needed.
for staff Code Red Fire All employees MRCC:
M- Move the Pt, R- Report the fire C- Close the doors G Contain the fire Code Blue External Disaster All employees Report to Instructor Cq~da Orange Hazardous Spill Designated No Response needed employees . _ . _...- -- - _ __.-_ . . ...... ... .. . . . _.- , . _--_ ..-.. ..
Code Pink Infant/ child All employees Go into the hallways, observe.
Abduction No one allowed to leave.
Code Green Hazardous V v Designated No response needed, che . micai emplgyoes Code Grey Mlissing 4 W AII employees Watch for lost resident.
resident . .........
_Special Indicators:
NO Code Yellow armband Pt. has a order to not resuscitate High Ftisk for Faits Green armband Pt. Assessed to be high risk, protocol on careplan Emotional Trauma Prnk 3- rose Placed on doorway to indicate Pt. dealing with an doorcard emotional trauma, check 4vith nurse before entering room.
Bereavement 8ereavement Card Placed on door to indicate Pt, has expired Figure 18-1 Response to code call, including student nurse.

18.3 EMTALA Requirements EMTALA is the "Emergency Medical Treatment and Active Labor Act", which covers the legal obligations of hospitals in the U.S. for emergency treatment.

From reference [ iv ], SUNY University Hospital guidelines:

1) EMTALA and the 250 yard rule: SUNY, for example, has inside team (adult and pediatric) and an outside team ("EMTALA"). The EMTALA team (a registered nurse and Public Safety people) responds to calls outside the main hospital buildings but within 250 yards from the main hospital buildings; the pediatric team is also called if it is a child.
EMTALA is the Emergency Medical Treatment and Active Labor Act, which ensures that a hospital cannot refuse aid to a patient that cannot pay and outlines how care must be provided.
2) Team members and equipment, specific for adult and pediatrics, are listed.... We were not far off r/e team members. There is a pediatric resuscitation cart and an adult resuscitation cart.
3) There are some timing protocols in section 1g... e.g. what happens if no one responds * * *

Dukes Memorial Hospital, Peru, Indiana, Undated.
'v Emergency Response Team, Administrative Policy Manual Policy E-15, SUNY
Upstate Medical University University Hospital, January, 2005.