Implementing a Common EMR and Network Architecture for Happy Health Systems

Running head: u10a1 Network and Security Architecture 1
u10a1 Network and Security Architecture
Kent Haubein
IT3350 – Network and Security Architecture
Q1 (2013) at Capella University
khaubein@gmail.com
Mansour Sharha

u10a1 Network and Security Architecture 2
Table of Contents
Executive Summary ......................................................................................................................................3
Scope and Requirements............................................................................................................................21
IP Addressing and Routing Architecture.....................................................................................................30
Naming Standards ......................................................................................................................................44
DHCP Addressing and Troubleshooting.....................................................................................................67
Network Management Architecture.............................................................................................................84
Performance Management Architecture .....................................................................................................91
Security and Privacy Architecture .............................................................................................................104
Network and Security Architecture............................................................................................................116
Conclusion.................................................................................................................................................130
References................................................................................................................................................131

Happy Health Systems
Executive Summary
Happy Health Systems is a healthcare organization consisting of four hospitals, ten clinics, a
physician practice and a research facility. The facilities cover a three state area. For the past five years,
Happy Health Systems has grown significantly adding three hospitals and six clinics within that timeframe.
Happy Health hospitals and clinics are administered by a single set of senior managers who all report to
the same board of directors. The research facility is governed by a management team made up of
members from the Happy Health board of directors, senior management and physicians from the
physician practice. The physicians manage their own physician practice and function as independent
contractors for Happy Health Systems. They are each responsible for their own billing and management
support processes.
Happy Health Systems plans to implement a common electronic medical record (EMR) system
that will be shared throughout the organization by all facilities. The EMR system is targeted to replace all
existing clinical systems in use with the exception of the radiology and lab system. Clinical directors have
been asked to compromise on a single solution. This integration of data into a single data source
between facilities will increase efficiency and allow doctors to speed up flow of information to access
patients’ historical information throughout the entire organization.
The final selections for clinical applications are:
 EPIC Electronic Health Record
 Phillips I-Site Radiology System
 Cerner Pathnet Laboratory Solution
All IT projects at the hospitals, clinics, physician practices, and research arm are proposed,
funded and implemented at the local facility level. Over time, this process has evolved where each

hospital has a unique radiology, laboratory, and emergency room system. The clinics operate on four
different types of practice management systems and run on a variety of software and hardware platforms,
including VMS, Windows NT, Windows 2000, Windows 2003, AIX, and Linux. Hardware and software are
purchased and maintained locally.
Happy Health Systems is using Active Directory Authentication. They have an empty root, which
is managed by IT staff who work at the original hospital. Each facility, including the physicians, practice
and research facility, has been structured as a separate domain. Facilities were allowed to choose
whether or not they wanted to “trust” the other domains within the forest. A few opted to do so, however,
most do not. Each facility has a pair of domain controllers.
A summary of usage follows:
 The number of users at each of the hospitals averages 2000
 The number of users at each of the clinics averages 100
 The physicians practice includes 45 physicians, 300 residents, and 200 medical students at any
given time
 The research facility includes 35 users.
The decision has been made to provide the following applications to all users throughout Happy Health
Systems in addition to the EMR system:
 MS Exchange e-mail.
 Microsoft Office Suite.
 PeopleSoft ERP (finance, supply chain, HR and Payroll modules).
 Symantec Security Suite.
 Spybot Search and Destroy.
The existing network is a mix of Cisco and Cabletron devices. Each site has a 100mb Ethernet fiber
backbone and the network segments from the core switches to desktop use CAT5e.

Analysis of the Existing Foundation for Execution
The present structure of Happy Health Systems is most reflective of a business silos operating
model that has evolved its alignment based upon health care business units, functionality, and
geographic location. The company has been growing at a fast rate and has fallen into the trap of
addressing immediate needs without regards to long term planning for future growth. The results have
been that IT projects for the physician practice and research arm have been proposed, funded and
implemented at the local facility level. Over time, this practice has evolved into the procurement of unique
systems for the hospitals’ radiology, laboratory and emergency room departments. Other typical side
effects of a business silos architecture model would be division of the physicians practice, clinics and
hospitals which have their IT investments focused on supporting local facilities. Currently, the ten clinics
of Happy Health Systems are using four different clinic practice management systems. This requires
local support and skill sets specific for supporting the different applications for the four types of software.
Each facility including the physician practice and research facility has been set up as a separate domain.
This requires local support and knowledgeable personnel to maintain these separate domains. There can
be certain benefits to companies having business silos such as encouraging innovative local
development, internal company competitiveness, customer satisfaction and positive response times.
However, the benefits for this type of structure do not outweigh the need for moving to a more mature
architecture level. The business silos architecture structure that currently exists within Happy Health
Systems limits the organization’s ability to accommodate future growth and increase financially. In order
for Happy Health Systems to achieve its main objective of implementing a common electronic medical
record (EMR) system it needs to implement a network architecture design supportive of its mission goals.
IT Capabilities
Happy Health Systems needs to move to a more mature architecture stage in order to leverage
down costs and improve service standards and IT capabilities. Happy Health Systems has four different

types of clinic practice management systems. These systems require specialized skill sets to support at
each site. Having unique systems imposes a communication barrier between different platforms and
creates additional needs to interlink the systems with external interfaces. These interfaces create a
requirement ‘outside’ the application which results in dependencies upon local talent and knowledge of
each system to integrate with each other. This becomes a point of failure and puts the company at
financial risk. Updates or code changes to these interface processes becomes time consuming and
expensive. Developers with exclusive knowledge of these interfaces can create “proprietary’ situations
and it becomes an added expense. Furthermore, a business silos architecture environment obstructs
integration and standardization of business processes (Ross, 2006). Happy Health Systems needs to
replace the four existing clinic practice management software systems with a single enterprise wide
solution to expand IT capabilities and achieve a greater maturity level for future expansion.
Business Objectives
The current Business Silos Architecture environment of Happy Health Systems limits the
company’s ability to standardize business processes and expand efficiency in order to support future
capabilities. Fast growing companies tend to fall into the trap of addressing immediate business without
regard for future expansion (Ross, 2006). The Happy Health Systems organization has grown
significantly in the past five years adding three of the hospitals and six of the clinics within that period.
Each facility including the physician practice and research facility has been set up as a separate domain
with two domain servers at each location. This non-standardization requires local support with
knowledgeable personnel to maintain these separate domains and does not support a shared
environment. By having separate domains, Happy Health Systems has a higher financial risk in the event
of system outage. Multiple domains also are less secure because the lack of standardization within the
configuration tends to be different for each domain and in most cases there are no local policies and
internal controls. Happy Health Systems can realize improved business processes and become more

efficient in their business process and IT operations by shifting away from the legacy business silos
architecture environment.
Funding Priorities
By moving up from a business silos level to a standardization technology stage of architecture,
Happy Health Systems can increase their bottom line. Some benefits of standardization technology
stages are t reduced operating costs such as support, maintenance and purchasing. Financial risks are
reduced by eliminating points of failure and increasing reliability uptime of the network. Security is also
improved because standards are implemented and enforced across the organization with the same
consistencies. Development time is improved because all developers use the same tool sets and can
share libraries of code without ‘reinventing the wheel’ every time a certain module is needed. It also
improves the quality of the applications developed in this environment and allows for future expansion.
Happy Health Systems has a variety of hardware and software including VMS, Windows NT, Windows
2000, Windows 2003, AIX and Linux. Hardware and software are purchased and maintained locally.
Happy Health Systems can reduce costs by migrating from these different hardware platforms and
operating systems into a company-wide standard that supports the IT infrastructure. Purchasing and
support could be performed by the IT staff at the original hospital. By using the same exact hardware and
operating systems at each location, support costs can be reduced, system uptime can be increased,
purchasing becomes more streamlined and maintenance contract costs are cheaper with bulk quantities.
The standardization technology stage of architecture is a more cost effective solution with the addition of
MS Exchange e-mail, Microsoft Office Suite, PeopleSoft ERP (finance, supply chain, HR and Payroll
modules), Symantec Security Suite, and Spybot Search and Destroy applications.

Key Management Capabilities
In order for Happy Health Systems to move into a standardization technology architecture stage,
they need to create a CIO position that aligns with their senior managers and reports to the board of
directors. According to Jeanne Ross, author of Enterprise Architecture as Strategy, companies that
migrate from a Business Silos Architecture to a Standardization Technology stage cling to the legacy
mindset that the business needs should drive technology (Ross, 2006). Happy Health hospitals and
clinics are administered by a single set of senior managers who all report to the same board of directors.
The research facility is governed by a management team made up of members from the Happy Health
board of directors, senior management and physicians from the physician practice. Without the presence
of a CIO or senior IT position at the senior staff level, Happy Health System lacks the commitment and
authority to mandate IT initiatives. Without the proper hierarchy and chain of command, the IT
infrastructure at Happy Health Systems will take a back seat to the business goals of the company.
Responsibilities for Defining Applications
The presence of a CIO at the senior staff level would benefit Happy Health Systems for defining
applications standards and achieve significant cost savings. Companies that shift to the standardization
architecture stage reduce costs by eliminating software that performs similar functions. According to the
text, one manufacturing company reduced the number of order entry management systems from twenty-
eight to four (Ross, 2006). Happy Health Systems has existed within a business silos environment. IT
projects were determined at the local level and over time the results have been the procurement of
different hardware platforms and unique software applications that support the unique radiology,
laboratory and emergency room at each hospital. Cost savings can be realized by Happy Health
Systems by integrating their existing applications into a universal software product that encompasses the
functions and scope of the existing system software. Overlapping of common data and compatibility
issues with interfacing of systems can be eliminated. Visibility to shared data can exist locally and at a

corporate level with data warehousing. An all-encompassing software product also reduces labor support
costs and increases reliability. Replacing all other clinical systems with the EMR in standardization
technology architecture provides an enterprise wide solution while improving health care service at a
lower cost.
IT Governance Issues
The business silos architecture model of Happy Health Systems presents a requirement to
establish IT governance. Happy Health Systems has a lack of control that is affecting the performance
and bottom line of the organization. Shifting to a Standardization Technology Architecture with a CIO or
senior IT position at the staff level will help Happy Health Systems support these issues. One example
that reflects the lack of IT Governance within in Happy Health Systems is that facilities were allowed to
choose whether or not they wanted to 'trust' the other domains within the company. A few opted to do so,
however most did not. Each facility has its own pair of domain controllers. This practice of allowing each
facility to choose adds additional costs to the company’s bottom line and is also a risk factor. The legacy
mindset of staff level managers has been to defer any related Information Technology decisions to
someone on the local IT staff because they lacked the technical knowledge or experience to make a
qualified decision. The practice much like the Happy Health domain example creates a decision process
that is not representative of all the company stakeholders. By handing off the decision through a single
channel, the process effectively isolates other functional areas of the company from participating in the
decision making process. In the event of performance issues or system outages, stakeholders in the
current company structure would suffer the consequences without any due process or expectations. A
service level agreement among all the stakeholders is a good preventative measure to ensure all the
stakeholders have been included.

Definition of the Operating Model of the Organization
The current business model within the Happy Health Systems limits the organization’s ability to
accommodate future growth and increase monetarily. Happy Health Systems needs to shift from a
business silos stage into the standardized technology architecture level in order accommodate future
growth and increase financially. With the rapid expansion of the organization’s growth in the past five
years with adding three new hospitals and six of the clinics, the standardized technology architecture
level will aid the company financially. In order for Happy Health Systems to improve efficiencies within IT
operations and give visibility for shared data to support business functions, the company needs to migrate
into the standardized technology architecture level. Improvements will be realized with IT capabilities
being enhanced, business objectives will be achieved, finances will increase, and management decisions
will be streamlined and more accurate. Defining applications will make the company more efficient and
accommodate future expansion, and IT Governance will give stakeholders buy-in to participate with the
direction of the company’s future. With the significant growth in the past five years, the move toward a
recommended replication operating model will support higher business process standardization and
integration. Surrounding Happy Health Systems with a replication operating model will improve
productivity and a strong foundation will be established to accommodate future expansion.
Proposal for Enterprise Architecture
Main Project Objectives:
Implement a common electronic medical record (EMR) system that will be used throughout the
Happy Health Systems organization by all of the facilities under its umbrella. This EMR system will
replace all other clinical systems throughout the organization with the exception of the radiology and lab
system. Clinical directors have been asked to compromise on a single solution. The final selections for
clinical applications are:

 EPIC Electronic Health Record
 Phillips I-Site Radiology System
 Cerner Pathnet Laboratory Solution
In addition to the EMR system, the following applications will be available to all users throughout Happy
Health Systems:
 MS Exchange e-mail
 Microsoft Office Suite
 PeopleSoft ERP (finance, supply chain, HR and Payroll modules)
 Symantec Security Suite
 Spybot Search and Destroy
Project Scope:
The scope of this project includes and excludes the following items:
In scope:
 Create a standardization technology architecture
 Implement a common electronic medical record (EMR) system throughout the entire organization
 Implement MS Exchange e-mail, Microsoft Office Suite, PeopleSoft ERP, Symantec Security
Suite and Spybot Search and Destroy available to all users
 Gather user requirements
 Gather application requirements
 Determine device requirements
 Determine network requirements
 Other requirements
Out of scope:
 Resources employed by subcontractors.
 Future software patches and OS – Operating System upgrades.
Approach:

 Develop a preliminary project scope statement or ROM – Rough Order of Magnitude. This will
involve additional input from the Happy Health Systems stakeholders that include representation
board of directors, senior management, physicians, hospital and clinic personal, medical
residents and students.
 Develop a project plan to facilitate actions from all involved members in the project.
 Direct and manage project execution which will require carrying out the project plan.
 Monitoring and controlling the project. The project team members will continuously monitor
performance and well-being of the upgrades.
 Change management. This will include coordinating CR – Change Requests to the appropriate
Happy Health Systems stakeholders to approval unit and system tests.
 Finalize project. CAT – Customer Acceptance Testing for pre-production cut-over processes.
 Close out processes. Customer sign off and acceptance. Lessons learned documentation and
final follow-up.
User Requirements:
Gather a set of requirements derived from Happy Health System personal that accommodates
environments to provide quick and reliable information access and offer quality service to the user
(McCabe, 2007).
 Timeliness
 Interactivity
 Reliability
 Presentation quality
 Adaptability
 Security
 Affordability

 Functionality
 Supportability
 Future growth
Application Requirements:
Determine the requirements of a common medical record (EMR) system that will be used
throughout the Happy Health System organization that is derived from application information,
experience, testing and represents the business needs for successfully operation on the system
(McCabe, 2007).
Application Types:
The selection of the EMR should be based on service and performance standards that include
mission-critical or RMA requirements, Rate-critical or high-performance capacity requirements, and real-
time interactive or high-performance delay requirements. Due to the nature of business performed by the
Happy Health Systems organization the selection of the common medical record (EMR) application
should include these elements in the final selection process.
Application Groups:
 Telemetry / Command-and-Control Applications – This is the process where data is
transmitted between remote devices for command control, tracking or determining status of a
remote device. Happy Health Systems has a business requirement for this type of application
with its use of RF devices in the four hospitals, ten clinics, physicians’ practice and research
facility.
 Visualization Applications - This type includes the two and three dimensional viewing of
objects, virtual reality viewing, immersion and manipulation of objects. This category of
application is recommended for Happy Health Systems due to the inherit nature of the health
equipment needed in the four hospitals, ten clinics and research facility.

 Distributed-Computing Applications. - This group includes applications have computing
devices that share, the same local bus, co-located on the same LAN – Local area network, MAN
- Metropolitan area network, and WAN - Wide area network. This type of application computing
is recommended for Happy Health Systems due to the geographical location of the facilities
covering a three-state area.
 Web Development, Access and Use Applications - This type is indicative of current interactive
equivalents of traditional remote device and information access utilities telnet and FTP. This type
of application is a cost effective solution that would be beneficial for Happy Health Systems to
accommodate interactive web sessions where amounts of health care data are small relative to
other application groups. One example could be for the posting of employee schedules by
department.
 Bulk Data Transport Applications – This type is when large amounts of data are desired to be
transferred through interactive or asynchronous sessions. Traditional instances would include
FTP sessions or automated bulk transfer from system generated data. One example for Happy
Health Systems would be in the requirements for the supply chain module to generate large batch
orders that process off hours to vendors sites.
 Tele-Service Applications: This group includes applications that provide video and data
concurrently delivered to groups of people such as teleconferencing, telemedicine, or
teleseminars (McCabe, 2007). This type of application is necessary for Happy Health System
due to the business needs of the organization to operate interactively across the geographical
location of the facilities covering a three-state area.

 Operations, Administration, Maintenance, and Provisioning Applications – These types of
applications are essential for Happy Health Systems for proper functioning and operation of the
network. Examples include, DNS – Domain Name Service, Mail Services / SMTP which is
required for MS Exchange email, address resolution services, network monitoring, network
management, security and systems accounting.
 Client-Server Applications – This type is where applications traffic flows in a client-server
fashion. Happy Health Systems will use this type for their PeopleSoft ERP, supply chain, HR and
Payroll functions. These are mission critical and interactive necessities.
Application Locations:
Identifying the usage of applications and their devices within an environment is useful in
engineering a network plan because it can optimize traffic flows and increase overall performance. As
part of this process, an application map needs to be established for Happy Health Systems containing the
location information in order to perform an analysis of the requirements for the various application groups
such as finance, supply chain, HR and payroll.
Device Requirements:
This requirement includes device types, performance of characteristics and location of devices on
a network that are required to support the Happy Health System applications.
 Device Types – Typical device types can be grouped into three different categories, generic
computing devices, servers, and specialized devices. This group includes handheld devices,
PCs, laptops, and medical equipment which are forms of access points into the network for
employees at Happy Health System.

 Performance Characteristics – The performance of the device components is an essential
objective in producing the final leg of the network environment. These components are integral to
the overall performance of the device itself and the end perspective to the Happy Health System
employees.
 Processors
 Memory buffers
 Network Interface Cards
 I/O device controllers and peripherals
 Drive performance
 OS performance
 Storage performance
One example would be the selection of interface NIC cards for Happy Health System devices.
Each site in the existing network has a 100mb Ethernet fiber backbone and the network segments from
the core switches areCAT5e. Proper selection of the device characteristics is important in order to
leverage maximum performance from the device itself as well as the overall system experience.
I/O modules and peripherals for client computers at Happy Health Systems are an important
aspect for hospital operations. Monitors, keyboards, printers, scanners, network cards, wireless devices,
USB ports, and disk controllers. I/O device controllers interface peripherals to the system and have built-
in pre-processor capabilities that offload work from the CPU. Device controllers are key factors for
network performance. One example would be the use of a USB port to interface health care instruments
like taking a patient's blood pressure.
 Device Locations – The location information for Happy Health Systems devices on the network
is a very important part of network performance in determining traffic flows in between devices. A
flow model is necessary to determine the level of networking needs in relationship to the device

distance between LANs, WANs, servers, Cabletron hubs, etc., The Happy Health Systems
organization consisting of four hospitals, ten clinics, a physicians practice, and a research facility
covering a three-state area.
Network Requirements:
Types of network requirements include constraints from existing networks, anticipated scaling,
interoperability between networks, support services, and architectural design guidelines (McCabe, 2007).
Happy Health Systems is currently using Active Directory Authentication with an empty root that is
managed by IT staff working at the original hospital. Each facility, including the physicians, practice and
research facility, has been structured as a separate domain. Facilities were allowed to choose whether or
not they wanted to “trust” the other domains within the forest. A few opted to do so, however, most do not.
Each facility has a pair of domain controllers. Happy Health Systems is an existing network structure
which that wants to implement a common electronic medical record (EMR) system along with a suite of
applications for all users throughout the network. This could impose some accommodation dependencies
and constraints with the existing network structure. Examples of these include the following:
 Location dependencies
 Performance constraints
 Network, system, and support service dependencies
 Interoperability dependencies
 Network obsolescence
In order to achieve stakeholders’ expectations and obtain the desired business results, each one of these
elements much be addressed in the system upgrade. A good approach for Happy Health Systems
network requirements would be to map out the existing network topology along with a new proposed
network topology. The caveat in being the new proposed topology should contain the recommended
standard elements of network design as stated in this proposal.

 Network Management and Security
 Monitoring for event notification
 Monitoring for metrics and planning
 Network configuration
 Troubleshooting
 Security Risk Assessment
As the requirements and analysis process continues for Happy Health Systems the following key
elements of the project need to be identified, collected, and evaluated:
Analysis on a Process Level
 Define requirement specifications for network architecture design
 Create requirements map for a network architecture design
 Classify the different types of requirements for a network architecture design
 Determine the ethical concerns of gathering requirements for a network architecture design.
IP Addressing and Routing Architecture
 Construct a network design that includes fundamental network components
 Analyze the methods for designing IP address schemes for a network
 Apply IP addressing and routing to a network design
 Identify methods of enhancing and extending IP address schemes
 Explain and implement strategies for IP address privacy and conservation on a network
 Identify methods for eliminating data redundancy and duplication of effort
Name Resolution
 Identify what components support and conflict with name resolution in network architecture
 Implementation of WINS, NetBIOS, and DNS protocols for network performance.
 Apply name resolution standards and architectures to network design
 Comply with ethical standards and implications of sharing network resources externally
Architecture and DHCP
 Implementation of DHCP on network
 Analyze the components within and external to DHCP architecture
 Analyze the methods for designing DHCP addressing

 Implement DHCP addressing, leasing, and architecture concepts for network design.
 Design network segmentation and network security.
Network Management Architecture
 Implement network management
 Identify functional areas addressed in a network management design
 Install network management tools
 Apply network management strategies to network architecture
 Identify the ethical and security risks, concerns, and implications related to the monitoring and
documentation of network activities
 Event logging strategies
Performance Architecture
 Analyze existing network performance and make recommendations
 Implement network tools to manage and monitor network performance
 Apply methods for managing and monitoring performance of a network
 Create architecture SLA - service level agreements for stakeholders sign-off
 Identify ethical and security, risks, concerns and implications related to the pressure to meet
network architecture service level agreements (SLA).
Security and Privacy Architecture
 Implement tools required to properly assess the security architecture.
 Determine the relationship of internal and external security to the security architecture
 Identify the mechanisms used to achieve a secure infrastructure
 Develop a security and privacy plan will maintain the ethical standards of both users and IT
administrators
 Create a multi-layered security architecture for a network
Secure Network Design Infrastructure
 Design a strategy for secure network management
 Develop a secure network management architecture appropriate for Happy Health Systems
 Identify the advantages and disadvantages of using sole source network service providers

 Implement strategies for hardening network devices
Architecture and Remote Access
 Identify technology alternatives for providing remote access
 Develop a strategy for the role of remote access and routing technologies
 Identify strategies for monitoring remote access solutions
Project Assumptions:
In order to identify and estimate the required tasks and timing for the project, certain assumptions
need to be made. Based on the current knowledge today, the project assumptions are listed below. If an
assumption is invalidated at a later date, then the activities and estimates in the project plan should be
adjusted accordingly.
 Project funding for Happy Health Systems be approved
 Subcontractor and vendor support will be available
 Share services space will be available to network users
 All work meets corporate standards.
Project risks:
Project risks are characteristics, circumstances, or features of the project environment that may
have an adverse effect on the project or the quality of its deliverables. Known risks identified with this
project have been included below. A plan will be put into place to minimize or eliminate the impact of
each risk to the project.
Risk area Level (H/M/L) Risk plan
1. Power outage during cut-
over
Medium Additional time built into the
project to allow for delays due
to power loss.
2. Availability of manpower
resources to complete work
Low Will have additional
contractors available if

needed.
3. Natural disaster Low Building insurance.
Stakeholder Representatives:
Name Role Position Contact Information
James Doe Sponsor CEO, HHS Jim.doe@hhs.com
Walt Doeser Team Member Board Directors Walt.doeser@hhs.com
Dr. Richard Dooer Team Member Sr. Mgr. HHS Opers Richard.dooer@hhs.com
Dr. Travis Dider Team Member Physician Travis.dider@hhs.com
Dr. Joe Smith Team Member Physician Joe.smith@hhs.com
Kate Owens Team Member Nurse, HHS Clinic Kdate.owens@hhs.com
Doggie Howser Team Member Lab Tech., HHS Doggie.howser@hhs.com
Dr. Joe Trauma Team Member Physician, HHS Emg Joe.trauma@hhs.com
Scope and Requirements Specifications
The purpose of the paper is to reveal the analysis based upon scope requirements
specifications for the Happy Health System organization. Each item addressed is based upon feedback
complied from stakeholder consisting of users, senior management, various IT groups, and local facility
personal. Each item in the listing is calorized by an assigned ID name, date, type, description, source,
location, status, and priority. Logic behind the priority is based upon the technological analysis and
stakeholder expectations about the projects main goals of implementing an enterprise wide EMR application,
MS Exchange e-mail system, MS Office Suite, PeopleSoft ERP (finance, supply chain, HR, and Payroll),
Symantec Security Suite, and Spybot Search and Destroy software. To accommodate the main goals of the
project some network modifications, additions and configurations are necessary as defined in the lists of
requirements. The requirements specification document also includes a sample template of the users’
questionnaire which addresses individual security needs and concerns. Items in the listing of requirements
are referenced to the Happy Health System network mapping document. The network mapping document
illustrates a high-level requirements map depicting geographic locations, organization functional
areas, network connections between locations and the physical layout for each organization

including locations, identifiers, devices, number of users at each location, local connections types
and the location of applications hosted at the Kansas City Hospital datacenter.
Requirement Specification
Section 1: Initial Conditions
Project Type Happy Health Systems Upgrade
Project
Scope
Four hospitals, ten clinics, a physicians practice, research facility spread over a three-
state area
Project
Goals
Implementation of EMR - Electronic Medical Record System and Network Architecture
Re-Design
Other
Conditions
Financial TBD
Problem
Evaluation and
Definition
Happy Health Systems has chosen to implement a common electronic medical record
(EMR) system that will be used throughout their organization by all of the facilities
under its umbrella. This EMR system will replace all other clinical systems in use
throughout the organization with the exception of the radiology and lab system. Clinical
directors have been asked to compromise on a single solution.
Section 2: Listing of
Requirements
ID
Name
Date Type Description
Source of
Informatio
n
Locatio
ns
Statu
s
Priorit
y
U 001
1/16/1
3
User
User distribution:
Each hospital averages 2000.
Each clinics average 100. The
physicians practice includes 45
physicians, 300 residents, and
200 medical students at any
given time. The research facility
includes 35 users. See Figure
01 and 02.
Gathered
from
Managem
ent
All Sites Info TBD

N 001
1/16/1
3
Networ
k
Current network:
The existing network is a mix of
Cisco and Cabletron devices.
Each site has a 100mb Ethernet
fiber backbone and the network
segments from the core
switches to desktop use Cat5e.
See Figure 02 - 08.
Gathered
from
Managem
ent
All Sites Info TBD
A 001
1/16/1
3
Applicat
ion
EMR system:
Implement a common electronic
medical record (EMR) system
that will be used throughout
their organization by all of the
facilities under its umbrella.
Application is considered
mission-critical for HHS. More
information is needed
See Figure 02.
Gathered
from
Managem
ent
All Sites TBD TBD
A 002
1/16/1
3
Applicat
ion
Enterprise Applications:
Implement the following
applications to all users
throughout Happy Health
Systems in addition to the EMR
system: MS Exchange e-mail,
Microsoft Office Suite,
PeopleSoft ERP (finance,
supply chain, HR and Payroll
modules), Symantec Security
Suite, SpyBot Search and
Destroy. Applications are
considered important for
business objectives and data
integrity must be maintained to
address appropriate ethical
concerns. Sarbanes Oxley
guidelines need to be
addressed during configuration
and setup. More information is
needed and questionnaire
template is pending. See Figure
02.
Gathered
from
Managem
ent
All Sites TBD TBD

N 002
1/16/1
3
Networ
k
Active Directory:
Change Active Directory from
an "Empty Root" structure into a
preferred enterprise
standardized technology
architecture model that uses a
single "Forest" structure
spanning the entire enterprise.
New structure needs to address
appropriate level of ethical and
privacy laws to be compliant.
See Figures 01 - 08
Gathered
from
Managem
ent
All Sites TBD TBD
D 001
1/16/1
3
Device
Hardware:
Standardize hardware and
operating systems for network
clients’ devices throughout
entire enterprise
See Figures 02 - 08.
Gathered
from
Managem
ent
All Sites TBD TBD
A 003
1/21/1
3
Applicat
ion
EMR Selection:
Clinical directors have been
asked to compromise on a
single solution. The final
selections for clinical
applications are:
• EPIC Electronic Health Record
• Phillips I-Site Radiology
System
• Cerner Pathnet Laboratory
Solution
Questionnaire template is
pending. See Figure 02.
Senior
Managem
ent
Enterpri
se wide
TBD TBD
N 003
1/21/1
3
Networ
k
EMR Servers:
Implement EMR server cluster
in a multi-tiered configuration to
leverage performance of
application. Reconfigure
memory space on the server so
that the EMR application runs in
its own dedicated space with the
processor resources allocated
to priority execution.
Configuration needs to address
appropriate level of security
access to address company
ethical and privacy policies.
See Figure 02.
IT Network
Group
KC TBD TBD

N 004 2/1/13
Networ
k
Network Switches:
Logically segment the network
switches on the backbone so
that the configuration prioritizes
traffic flows to accommodate the
EMR core client access points
in the distribution model.
IT Network
Group
Enterpri
se wide
TBD TBD
N 005 2/2/13
Networ
k
Backup routers:
Implement backup routers in
network topology as a
contingence to maintain network
uptime.
IT Network
Group
All
Hospital
s and
Physicia
ns
Practice
TBD TBD
N 006 2/2/13
Networ
k
MS Exchange e-Mail Server:
Implement dedicated MS
Exchange e-mail server to host
enterprise wide access for e-
mail clients within the entire
Happy Hospital System
organization. The server is to
be centralized at the Kansas
City Main Hospital computer
datacenter. Configuration needs
to address appropriate level of
security access to address
company ethical and privacy
policies. See Figure 02.
IT Network
Group
KC TBD TBD
N 007 2/2/13
Networ
k
File Server:
Implement file server with
Microsoft Office Suite,
Symantec Security Suite,
Spybot Search and Destroy to
host enterprise wide access for
applications to authorized
users/groups. The server is to
be centralized at the Kansas
City Main Hospital computer
datacenter. Configuration needs
to address appropriate level of
security access to address
company ethical and privacy
policies.
See Figure 02.
IT Network
Group
KC TBD TBD

N 008
2/10/1
3
Networ
k
PeopleSoft ERP Server:
Implement ERP server cluster in
a multi-tiered configuration to
host enterprise wide application
access for finance, supply
chain, HR and Payroll modules
to authorized users/groups.
Configuration needs to address
appropriate level of security
access to address company
ethical and privacy policies.
The server is to be centralized
at the Kansas City Main
Hospital computer datacenter.
See Figure 02.
IT Network
Group
KC TBD TBD
N 009
1/21/1
3
Networ
k
IP Addressing and Routing
Architecture:
• Construct a network design
that includes fundamental
network components
• Analyze the methods for
designing IP address schemes
for a network
• Apply IP addressing and
routing to a network design,
• Identify methods of enhancing
and extending IP address
schemes
• Implement strategies for IP
address privacy and
conservation on a network
• Identify methods for
eliminating data redundancy
and duplication of effort
Gathered
from
Managem
ent
All Sites TBD TBD
N 010
1/21/1
3
Networ
k
Name Resolution:
• Identify what components
support and conflict with name
resolution in network
architecture
• Implementation of WINS,
NetBIOS, and DNS protocols for
network performance.
• Apply name resolution
standards and architectures to
network design
• Comply with ethical standards
and implications of sharing
network resources externally
Gathered
from
Managem
ent
All Sites TBD TBD

N 011
1/21/1
3
Networ
k
Architecture and DHCP
• Implementation of DHCP on
network
• Analyze the components within
and external to DHCP
architecture
• Analyze the methods for
designing DHCP addressing
• Implement DHCP addressing,
leasing, and architecture
concepts for network design.
• Design network segmentation
and network security.
Gathered
from
Managem
ent
All Sites TBD TBD
N 012
1/21/1
3
Networ
k
Network Management
Architecture
• Implement network
management
• Identify functional areas
addressed in a network
management design
• Install network management
tools
• Apply network management
strategies to network
architecture
• Identify the ethical and security
risks, concerns, and implications
related to the monitoring and
documentation of network
activities
• Event logging strategies
Gathered
from
Managem
ent
All Sites TBD TBD
N 013
1/21/1
3
Networ
k
Performance Architecture
• Analyze existing network
performance and make
recommendations
• Implement network tools to
manage and monitor network
performance
• Apply methods for managing
and monitoring performance of
a network
• Create architecture SLA -
service level agreements for
stakeholders sign-off
• Identify ethical and security,
risks, concerns and implications
related to the pressure to meet
network architecture service
level agreements (SLA).
Gathered
from
Managem
ent
All Sites TBD TBD

N 014
1/21/1
3
Networ
k
Security and Privacy
Architecture
• Implement tools required to
properly assess the security
architecture.
• Determine the relationship of
internal and external security to
the security architecture
• Identify the mechanisms used
to achieve a secure
infrastructure
• Develop a security and privacy
plan will maintain the ethical
standards of both users and IT
administrators
• Create a multi-layered security
architecture for a network
Gathered
from
Managem
ent
All Sites TBD TBD
N 015
1/21/1
3
Networ
k
Secure Network Design
Infrastructure
• Design a strategy for secure
network management
• Develop a secure network
management architecture
appropriate for Happy Health
Systems
• Identify the advantages and
disadvantages of using sole
source network service
providers
• Implement strategies for
hardening network devices
Gathered
from
Managem
ent
All Sites TBD TBD
N 016
1/21/1
3
Networ
k
Architecture and Remote
Access
• Identify technology alternatives
for providing remote access
• Develop a strategy for the role
of remote access and routing
technologies
• Identify strategies for
monitoring remote access
solutions
Gathered
from
Managem
ent
All Sites TBD TBD

Section 3: Template
Questionnaire
Happy Health
Systems
User name: James Doe
Login ID: doehhkc
Facility Location: Kansas City Hospital
Room #: 102
Depart: Finance
1. List applications that you use
How Often per
day?
Duration Time
Application #1: EPIC Electronic Health Record Continuous 7 hrs
Application #2 : Cerner Pathnet Laboratory Solution Once 20 min
Application #3 : Phillips I-Site Radiology System Once 10 min
Application #4 : e-Mail via browser Continuous 8 hrs
Application #5 :
2. List of computers or other devices connected to network
Network
Interface
Operating
System
Device #1: Desktop 100mb Win2000
Device #2: Laptop 100mb Win2003
Device #3:
3. List capabilities preferences (performance, features)
Performance -: High requirement for EPIC system due to daily
usage.
Features - MS Exchange e-mail, ERP (finance), MS Office Suite
are desired
Other -
4. Please list any security issues or appropriate ethical
concerns that you require

Security requirements - Need access to finance group, payroll
data Compliance issues - User id access to user group finance in
shared area
Sarbanes Oxley – Winzip for encryption file transfers needed
Other -
5. Any other suggestions, issues, or comments?
Suggestions - Upgraded OS on desktop and laptop would be nice
Issues -
Comments -
Other -
IP Addressing and Routing Architecture
physician practice and a research facility. The facilities cover a three state area, including Kansas,
Nebraska and Missouri. For the past five years, Happy Health Systems has grown significantly adding
three hospitals and six clinics within that timeframe. In order for Happy Health System to perform their
mission statement, the organization will require public and private IP addressing in an IPv4 network
environment. The purpose of IP addresses is for identification and intercommunications within the
company intranet (private) and externally on the internet (public). Each hardware device within the Happy
Health Systems enterprise will have an IP address that is dynamically assigned or statically assigned. IP
addresses are a 32 bit number divided into sections called octets with octet ranging from 0 to 255.
Happy Health Systems a large mature organization so redundant data mapping of the IP
addresses within the enterprise needs to be tackled prior to beginning the project. The addressing
strategy for this network architecture project should be to avoid having to change schemes and
reconfigure device addresses during the life cycle of the network (McCabe, 2007).

There are three classes of public IP addresses available for general public use: class A, class B
and class C. Typically, Hospitals and Universities are best suited for Class B IP addressing schemes
because they have a significant amount of devices within their organizations. Because Happy Hospital
Systems has grown significantly in the past five years, it has a public Class B IP address assigned to the
organization of 190.16.8.96. Class B addresses fall in the range of 128.0.0.0 to 191.255.255.255. This
allows Happy Health Systems to publically address 65,532 devices on the network. This threshold of
available public addresses should suffice for devices to communicate in the public domain for the next ten
years until the implementation of the new version IPv6 network environment that extends the size of an IP
address to 128 bits.
Network Address Translation - NAT
The private IP addressing scheme for Happy Health Systems allows all devices to communicate
internally over the companies’ intranet at an exceptional rate which are hidden from the outside public
world (internet). The Happy Health Systems organization can use these internal private numbering
schemes without conflict to the outside world because they are hidden behind assigned public IP address
of 190.16.8.96 known as the network ID. The NAT – Network Address Translation configuration in Happy
Health Systems router/firewall allows the assigned public address of 190.16.8.96 to send and receive
data from the private addresses contained within the intranet across the public internet. The purpose of
the NAT device is to intercept data packets on inbound or outbound traffic messages and re-address the
information as to aid in its delivery through the combination of the public network ID and private device
address. The process of combining addresses is known as “route aggregation” or port address
translation (NAPT). The configuration of the NAT translation in the router of firewall is an important
process because it keeps everyone at Happy Health Systems happy with the proper delivery of their data.
Prior to NAT there a public IP addressing network system known as CIDR – Classless Inter-
Domain Routing. Introduced around 1993, it was a popular mechanism for addressing networks as it was

an efficient method of allocating remaining IP address space since most Class A and B addresses had
been allocated (McCabe, 2007). By today’s standards, CIDR is a “patch” that allows continuous
networking with the caveat where it must be used in conjunction sitting side by side with legacy networks
which were based on the original Class A and B networks. CIDR is a more efficient method for “route
aggregation” as it can combine several routes into a single routing table entry, however with the advent of
IPv6 in the future NAT is a more cost effective solution because it allows Happy Health Systems to use
unregistered IP network numbers internally on their intranet.
Determining the Number of Subnets for the Happy Health System Network
Each WAN connection requires a subnet to support IP routing. The Happy Health System
organization consists of 16 WAN connections consisting of T-1 Frame and Factional circuits. This
requires a minimum number of 16 subnets. The number of devices at each hospital and physicians
practice requires these sites to have multiple subnets assigned. The number of users at each hospital
averages 2000 and the physicians practice includes 45 physicians, 300 residents, and 200 medical
students at any given time. At the average number of devices at each hospital and physicians practice is
estimated to be around 600 that require a minimum of three subnets per site. However with the continual
growth of the Happy Hospital Systems organization four subnets per site is recommended to avoid having
to change schemes and reconfigure device addresses during the life cycle of the network equipment.
Maintain Privacy on a Network
Happy Health Systems needs to incorporate IT Governance procedures for their organization that
adhere to professional code of ethics. They must ensure that information technologist personal
responsible for defining the organization’s IP addressing scheme complies with the companies’ ethical
policies and code of conduct. Following these procedures is essential in safe guarding intellectual
property, copyrights, ownership of information, and invasion of privacy. A key element is the addressing

strategy for Happy Health System this network architecture to avoid redundant data mapping. It is
possible to use the same numbering schemes on separate subnets within an organization, however from
a security perspective this could result in several issues. One example is the ten clinics for Happy Health
Systems using the same number schemes at each location. In this scenario, if an employee on the
network was performing some unauthorized or illegal action on a company workstation it would be difficult
to pin down the exact device where the infraction occurred. Another possible issue could be software that
has a dependence upon the host IP address. This could result in packet collusions as traffic gets routed
to a conflicting device or the possibility of invasion of privacy. It makes good business sense for the IT
personal at Happy Health Systems to employ these boundaries when addressing the network architecture
to maintain privacy on the network.
Figure 01 through figure 06 shows a high-level requirements map depicting the network topology
which includes IP addressing for both the LANs and WANs for the Happy Health Systems organization.

Top Level View – Happy Health Systems Network
Figure 01

Omaha NE Network – Happy Health Systems
Figure 02

Lawrence KS Network – Happy Health Systems
Figure 03

Springfield MO Network – Happy Health Systems
Figure 04

Physicians Practice Network – Happy Health Systems
Figure 05

Research Facility Network – Happy Health Systems
Figure 06

Analyzing network traffic for Happy Heath Systems
The screenshots in figure 07 through 13 illustrate a simulation of the baseline network and
statistics for Happy Health Systems utilizing the OPNET – Optimum Network Performance too. The
purpose of this tool is to verify the network will operate sufficiently when additional traffic loads are
applied. The graphs shown represent “what-if” comparisons that conveniently store baseline network
scenarios that allow the network architect to experiment and simulate different conditions. This aids in
the network design and is a cost effective solution for Happy Health Systems to design and maintain their
network enterprise topology.
Top level View of Happy Health Systems
Figure 07

Figure 08
Figure 09

Figure 10
Figure 11

Figure 12
Figure 13

Naming standards
DNS and WINS Name Resolution
physician practice and a research facility. The facilities cover a three state area, including Kansas,
Nebraska and Missouri. For the past five years, Happy Health Systems has grown significantly adding
three hospitals and six clinics within that timeframe. In order for Happy Health Systems to maintain a
solid performance based architecture design the namespace components of the network structure should
accommodate current traffic flows and future growth within the organization. The systems at Happy
Health Systems run on a variety of hardware and software, including VMS, Windows NT, Windows 2000,
Windows 2003, AIX, and Linux. With these combinations of hardware devices, the recommended
namespace resolution for Happy Health Systems will be DNS – Domain Name System and WINS –
Windows Internet Name Service.
Understanding of the concepts of DNS and WINS
DNS – Domain Name System is a distributed online database name resolution process where a
DNS server translates a domain name into an explicit IP address so that a client device can resolve and
route packets to the destination host (Brain & Crawford, 2013). DNS is platform independent and is
mainly used for servers and network devices. DNS is a good choice for Happy Health Systems due to
the mixed variety of operating systems used on devices throughout the organization. Figure 14 illustrates
a high level example of how a DNS server operates in a network environment. In this scenario, a
workstation makes a call to a DNS server to resolve the IP address of a fully qualified domain name
“www.yahoo.com”. The closest DNS cannot resolve the request and forwards the request to a secondary
DNS server. The secondary DNS server has the information and returns the mapped IP address of
“98.139.183.24” back to the first DNS server so that is can update its cache with the information. The

mapped IP address is then returned back to the client workstation. The workstation now has an
awareness of the explicit IP address of “www.yahoo.com” as “98.139.183.24”.
Figure 14

WINS - Windows Internet Name Service as the name suggests is a Microsoft product that is
specifically designed for Windows based systems such as workstations, laptops, and NT servers
(Microsoft, 2013). Unlike DNS, WINS is basically platform dependent and is used in conjunction with
DHCP - Dynamic Host Configuration Protocol systems were IP addresses are dynamic assigned to
devices and can change frequently. By comparison, DNS servers are primary used for static IP
addresses and do not support DHCP as were WINS does. WINS has some advantages over DNS such
as reducing query broadcast traffic over a network because clients can query a WINS server directly
within the broadcast area. WINS enables the computer browser service to collect and distribute browse
listings across IP routers. Figure 15 illustrates an example of how WINS operates in a Microsoft network
environment. In the scenario, Client “B” sends a request for Client’s “A” IP address. Client “A” has
broadcasted its registration with the WINS servers so the WINS database has an awareness of the IP
mapping for Client ”A” and returns the information back to Client “B”. WINS supports replication which
also serves a dual purpose for fault tolerance when a secondary WINS servers is located within the same
broadcast area. Just like DNS, WINS supports centralized management and replicates namespace
mappings to other WINS servers (Microsoft, 2013). WINS and DNS are a good choice for Happy Health
Systems network environment because they provide combined search functionality for namespace
resolution. In the Happy Health Systems network, the hub and spoke design allows for WINS replication
at each local site. Each facility within the organization has the capability to be configured as push/pull
partners. WINS data is kept up to date with a minimum of WAN traffic and clients can resolve NetBIOS
names from any location. Having two or more WINS servers in each location provides fault tolerance and
ensures performance.

Figure 15

Implementing DNS and WINS
The recommended DNS and WINS servers for the Happy Health Systems organization are based
upon the physical locations and number of hosts that can be supported at each site (Microsoft, 2013). .
Typically each location will have at least one DNS server and several WINS servers. The approach for
supporting the business needs and rationale are based upon determining the following requirements.
 Number of host at each site
 Usage of legacy DNS servers that exist in the current network architecture
 Consideration of Active Directory and integrating zones into the DNS design
 Determine if clients are located in the same broadcast domain. It there are in separate broadcast
domains then Microsoft recommends using WINS
Figure 16 shows the number of devices within the Happy Health Systems organization. The
number of users at each of the hospitals averages 2000, clinic users’ average 100, the physicians
practice includes 45 physicians, 300 residents, and 200 medical students at any given time, and the
research facility includes 35 users.
Figure 16

Namespace Requirements
Happy Health Systems currently uses their namespace on the internet and has an implemented
Active Directory that effectively represents the entire organization. The root top-level domain name of
“corp.happyhealthsys.org” is registered with ICANN – Internet Corporation for Assigned Names and
Numbers and is integrated with their Active Directory namespace hierarchy. Happy Health Systems plans
to use unique registered DNS namespace for their internal namespace. This improves security because
external users do not have access to private namespace, has minimal effect on the existing namespace
and requires minimal effort on the part of the current DNS administrator.
Applications at Happy Health Systems that rely on NetBIOS for name resolution need to be
factored into the namespace design. While DNS is the default naming resolution for Windows Servers
2003 there still maybe legacy applications that still use NetBIOS over TCP/IP (NetBT) in some older
clients. The final selection for the new EMR system along with updating older client hardware will help
remedy this concern. It is recommend that Happy Health upgrade its legacy Windows NT systems
because of the name resolution dependence of NetBT for older clients that run on earlier versions of
Windows 2000 and for Windows 2003 workgroups that do not accommodate Active Directory.
The decision has been made to implement Microsoft BackOffice and MS Exchange e-mail to all
users throughout Happy Health Systems. These applications and mail configurations on the Microsoft
Exchange Server will require NetBIOS naming conventions. One example of a common service that
requires NetBIOS namespace resolution is the File and Printer sharing on computers running Windows
2003. At computer startup, the MS File and Print service registers a unique NetBIOS name based upon
the computers name. This registered NetBIOS name allows the printer service to route submitted print
jobs to the queue of the destination printer.

Other considerations for the Happy Health Systems network design should include internet
visibility and the organization’s registered DNS domains names. Security policies of the organization
need to be addressed and applied during the configuration of the DNS and WINS servers. The growth of
Happy Health Systems has been significant in the past five years, adding three additional hospitals and
six of the ten clinics within that timeframe. These growth patterns need to be factored into implementing
DNS and WINS in the network to accommodate future expansion.
Active Directory
Happy Health Systems is using Active Directory Authentication. They have an empty root, which
is managed by IT staff who work at the original hospital. Each facility, including the physicians, practice
and research facility, has been structured as a separate domain. Figure 17 illustrates the domain name
system for Happy Health Systems. According to Microsoft, a well-planned structure reduces the risk of
internal and external connectivity issues, ensures resource record integrity, and allows for future
expansion potential (Microsoft, 2013).

Figure 17
Integrating DNS servers with Active Directory at Happy Health enables domain controllers to
automate namespace undertakings such as host registration and zone replication. The hierarchical
namespace design with multiple subdomains concept supports different physical DNS locations and can
be named to aid in administration of DNS within the enterprise. Figure 18 illustrates the public and
private namespace design for Happy Health Systems. The external advertised namespace is
“corp.happyhealthsys.org” and the internal namespaces are prefixed with “hosp, phys, res., etc.” such as
“hosp.corp.happyhealthsys.org”. This subdomain naming convention of the public namespace is the
most common practice and recommended by Microsoft because it prevents overlapping of internal and
external namespaces which can result in resolution problems with multiple authoritative zones (Microsoft,
2013). The subdomain structure is also recommended for an existing DNS namespace that is integrated
with Active Directory.

Figure 18
Planning Zones
A good solution for Happy Health Systems DNS zone planning will be Active Directory-integrated
zone. This allows the DNS zone servers to integrate into the existing Active Directory Structure and
provides a single point of support for both DNS and Active Directory. Happy Health Systems has an
empty root and is managed by IT staff at the Kansas City hospital. A primary zone server will be used at
this site where all resource record updates of additions and deletions will occur. Zone information will
periodically be transferred to DNS servers hosting secondary zones to ensure synchronization across the
network. Initially the primary server will transfer a full copy of the zone file information to secondary zone
servers and then subsequently sends only changes that occur. The Active Directory integrated primary
zone information is replicated by Active Directory to other hosting servers configured with Active

Directory-integrated zone. An example would be the replication of zone information between the primary
zone server at Kansas City and the DNS servers located at the hospitals and physician practice facility.
Once these servers are primed with the initial full copy of resource records, then only incremental change
records are replicated across the network. This aids in network performance and leverages the Active
Directory features for secured dynamic updates between zones. Another benefit of this design allows the
utilization of DHCP servers within network to dynamically update DNS along with DNS clients running
Windows 2000, Windows XP and Windows Server 2003.
Configuring DNS and WINS for Network Performance
The role of naming standards that DNS and WINS play in network performance is essential in
maintaining acceptable levels for capacity, delay and RMA in a network (McCabe, 2007). Happy Health
has a variety of hardware and software that includes both Windows and non-Windows systems that
includes VMS, Windows NT, Windows 2000, Windows 2003, AIX, and Linux. In order for the Happy
Health Systems network to maintain high level response times and throughout put for client’s namespace
requests, the DNS servers should be configured for WINS lookup and WINS reverse lookup. Configuring
the DNS servers for WINS Lookup allows the DNS servers to directly query WINS servers for name
resolution so that DNS clients can look up names and IP addresses of the WINS clients that cannot be
resolved by querying DNS domain namespace. This reduces network traffic within the broadcast area
and improves performance of name resolution lookup time. Once integrated, the WINS resource record
can be enabled for WINS lookup into forward lookup zones. The WINS-R resource record can be
enabled for node adapter status requests for reverse lookup zones. The example in Figure 19 illustrates
the process flow from a DNS client query to a DNS WINS enabled server to resolve name resolution.

Figure 19
WINS-R known as WINS reverse lookup can be added to recursively lookup zones. The DNS
service cannot send a reverse name lookup to WINS for name resolution of a computer by its IP address,
because the WINS database is not indexed by IP addresses. Therefore with WINS-R enabled the DNS
service sends a node adapter status request directly to the implied IP address contained within the DNS
query. Upon receipt back with the NetBIOS name, the DNS service appends domain name back onto the
NetBIOS name provide from the node status response and then forwards the results back to the
requesting client (Microsoft, 2013). This solution provides a means of backwards compatibility for the
Happy Health Systems mixture of hardware devices located at the clinic facilities throughout the
organization. As additional traffic can be generated with WINS-R enabled, the recommendation for

Happy Health Systems is too only use WINS-R in zones where a mixture of non-Windows and Windows
clients co-exist. Another DNS feature that will aid in network performance is the Time to Live (TTL)
feature contained within each DNS server. TTL is a configuration value consisting with the amount of
time in each zone that decides the length of time the data records remain in the DNS servers’ cache.
Smaller TTL values help to ensure that data within the domain is more consistent across the network.
The downside to smaller TTL values however can also increase traffic loads on the name server. If data
within WINS rarely changes then the TTL can be increased to reduce the number of queries between
DNS and WINS servers. The Happy Health Systems clinics are a good example where the WINS rarely
changes and their upstream DNS server can leverage better performance with an increase to the TTL
values.
DNS and WINS Network Diagrams
Figures 20 - 26 illustrate the recommended DNS and WINS namespace resolution design
strategy for the Happy Health Systems healthcare organization. The legend at the bottom of each
diagram reveals the applied concepts.

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28 - 31. OPNET update of network diagrams including DNS and WINS information and
naming standards.
Figure 28

Figure 29

Figure 30

Figure 31

Dynamic Host Configuration Protocol (DHCP)
Dynamic Host Configuration Protocol (DHCP) is a technology that allows for the dynamic
assignment of IP addresses to devices on a network. Most organizations today have implemented this
protocol in their network architecture structure (Microsoft Learning, 2013). The proper placement of
DHCP servers in the Happy Health Systems network is essential in achieving efficient levels of service.
DHCP is an effective method in terms of non-human support costs and proven technology that prevents
duplication of IP addresses assigned on a network. From a security perspective, the downside tradeoff
would be the unattended human factors were a breach could occur with a device plugged into an
unmanaged port thus obtaining unauthorized permission to a network. This document will present
strategies to mitigate some of these risks, offer a common solution for handling static IP addresses for
servers differently than workstations, and present a network diagram of the Happy Health Systems
organization that reveals routing architecture information.
Implementation Strategy
In a distributed DHCP infrastructure the recommendation by Microsoft is to locate a DHCP server
on each subnet (Microsoft Learning, 2013). Happy Health Systems is a combination of centralized and
distributed infrastructure and will require additional servers for redundancy located at the hospital sites
and at the Physicians Practice. In a combined DHCP infrastructure the location of the DHCP servers is
based upon the physical characteristics of the LAN and WAN network and not based upon logical
structures such as Active Directory or defined logical groupings. The diagram in figure 32 illustrates a
hub and spoke topology for Happy Health Systems that will provide a centralized DHCP infrastructure.
The four hospitals sites will forward DHCP broadcasts to and from client devices across the WAN link for
the ten clinics and research facility. This method will reduce dedicated server costs organization wide by

configuring routers positioned between the hospital and clinics to forward the DHCP broadcasts.
Windows servers 2003 or greater can act as a DHCP bootstrap protocol relay agent in instances were a
legacy router might be non-supportive. This layout for the infrastructure will achieve the best possible
performance by limiting the number of clients per DHCP server to fewer than 10,000. Each DHCP server
will be defined well below the recommend 1,000 scopes threshold and will have plenty of room for future
growth. In order to provide fault tolerance and availability, each hospital and the physicians practice will
be splitting DHCP scopes between two servers. If one of the servers becomes unavailable the other will
automatically assume the scope and continue to lease new IP addresses or renew existing IP addresses.
Splitting DHCP scopes also helps balance server load performance. Each of hospital DHCP servers will
assign their respective subnet scopes to both serves and in some locations there will be excluded
portions of the address ranges. Each DHCP scope will reserve IP addresses for servers and other
network devices that require a static IP address. Optionally each hospital and the physicians practice can
utilize an existing server to be configured as standby DHCP server in the event of an outage or failure by
one of the active DHCP servers. The standby server’s scopes will not be activated and only be put into
service by an administrator as needed.
Lease Parameters
Static IP Assignments
The main purpose of DHCP technology is for the dynamic assignment of IP addresses on
network devices while reducing the administrative support involved in configuring IP networks. The type
of IP address assignment is largely based upon the type of host device being served. As a common rule
most network devices such as desktop computers and laptops which are routinely booted, connected, or
disconnected from a network and get dynamic assigned IP addresses. Other devices that require
constant connections with host service dependences are usually better suited to have a static IP address
assignment manually assigned. Examples of these devices that provide service on a network include

servers, routers, switches, gateways, and printer servers. Static IP addresses remain the same during
each boot and only have to be configured once. Static IP addresses are established as reserved
addresses within the DHCP scope configuration.
Leased IP Assignments
Leased IP addresses are assigned from a pool of addresses for a particular subnet and each
assignment comes with a default lease time and maximum lease time. The server uses the default least
time unless the client specifies a least time option when it sends a request message to the DHCP server.
Both the default and the maximum leases policies have a maximum of 136 years with no minimum least.
Either of these lease parameters can be set as infinite. Establishing the lease time parameters depends
upon the network, devices, servers, and the amount of clients and must be judged on a case by case
basis. The bottom line in choosing the lease times for a network comes down to a trade-off between
stability and allocation efficiency (The TCP/IP Guide, 2013). The recommended strategy by Microsoft is
to extend the length of the lease time and the renewal duration to improve the performance of a DHCP
server (Microsoft Learning, 2013). The primary advantage of extending the least times is that the
addresses of the devices on the network remain relatively stable. The client device operates with
consistency, less network traffic is required, and the usage of dynamic DNS settings remains unchanged.
This strategy mitigates some of the associated risk with the use of this protocol in situations were having
IP addresses of devices “bouncing” all around the network can cause serious complications. Configuring
a DHCP server with a limited lease is typically not optimal under normal conditions and results in breaking
connections when the lease expires and the device is given a new IP address. The main disadvantage of
using extended leases is that it substantially ties up IP addresses that are no longer in use on a subnet
and can create gaps for efficient allocation or “wasted time” during the remainder of the lease (The
TCP/IP Guide, 2013). For this reason the DHCP configuration should be adjusted to fit the needs of the
organization. One example would be the clinic facilities at Happy Health Systems. Since most of these
client devices located at the clinics rarely change in functionality it would be wise to establish a higher

least time on their IP address assignments. In other situations at the hospitals it may be best to use
shorter leases do to the overall size and scope of the required IP addresses needed within multiply
subnets. Using shorter leases should be determined on a case by case basis where the available
number of addresses must be conserved due to limitations with the available IP addresses within a
subnet.
Figure 32

Figures 33 – 37 illustrate the DHCP scopes for each site.
Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

OPNET DHCP Network Diagram
The diagram in figure 38 represents a high level view of the Happy Health Systems organization.
Figures 39 – 43 illustrate pseudo versions of each Hospital and the Research Facility. The naming
conventions and DCPH server objects used in this OPNET representation are shown separately for
identity purposes and to analyze various simulations.
Figure 38

HHS Kansas City Hospital
Figure 39

HHS Omaha NE Hospital
Figure 40
HHS Lawrence KS Hospital
Figure 41

HHS Springfield MO Hospital
Figure 42
HHS Physicians Practice
Figure 43

Simulation Runs
Figure 44 shows the individual statistics chosen in Node statistics for Server DB, Server DB
Entry, and Server DB Query items.
Figure 44

Figure 45 shows the simulation run time of 40.0 minutes
Figure 45

Figures 46 – 47 show the results for HHS_OM_DHCP_2 simuation run.
Figure 46
Figure 47

Network Management Architecture
The essence of network management architecture is the understanding of what to monitor, what
to manage, determining the location of network management functions, and managing the flows of
network management traffic (McCabe, Network Analysis, Architecture, and Design, 2007). One of the
most common process methodologies for network management in use today is FCAPS which stands for
Fault-management, Configuration, Accounting, Performance, and Security (Rouse, 2013). FCAPS is
categorical model and framework of objectives for network management developed by ISO – International
Organization for Standardization. Following FCAPS guidelines is the recommended methodology
approach for the Happy Health Systems organization in achieving the objectives for their network
management architecture. This document will present strategies for the Happy Health System
organization to meet their business needs with the use of the FCAPS management framework model. It
will provide specifications of Nagios tools used in support of the infrastructure, indicate what will be
monitored and managed, placement of management functions, and illustrate the flow of management
network traffic within the network.
Fault-management, Configuration, Accounting, Performance, and Security (FCAPS)
Fault-management
Fault-management is the established monitoring of fault instances that have a negative impact in
a network. The objective is to recognize weaknesses, log fault instances that occur, use trend analysis to
detect flaws, isolate problems, and take corrective action to ensure that a network is maintained in an
optimal state with minimal downtime. Fault-Management would be the use of network management
mechanisms that include network management protocols. According to McCabe, there are currently two
major network management protocols, SNMP – Simple Network Management Protocol and CMIP –
Common Management Information Protocol (McCabe, Network Analysis, Architecture, and Design,

2007). Both these network management protocols provide mechanisms for retrieving, changing, and
transporting network management data across the network. The Nagios monitoring utility offers several
tools that support the fault-management functions of the FCAPS model which include, alarm correlation
analysis, alarm filtering, forwarding, handling and generation, diagnostic testing, error handling and
logging, calculation of error statistics, fault detection, isolation and correction, and network recovery.
An example of Nagios monitoring utility would be the usage of SNMP to monitor the RAID status on a
remote server. An SNMP agent service running on the local monitoring node at the Omaha Hospital
would reveal information back to the Nagios network management system located in the centralized
location in Kansas City. The network management application is able to dissect the returned information
via MIB – Management Information Base which is used to define variables within the SNMP protocol and
points back directly to the object located in Omaha. This helps Happy Health Systems in meeting their
organizations business objectives by improving network reliability for stakeholders while reducing support
costs.
Configuration-management
Configuration-management is the collection and storage of configuration data for variety of
devices located on a network. The objective is to simplify configuration procedures for each device on a
network, continually log updates of additions, changes, and modifications to devices, perform inventory
tracking of various types of devices, provide expansion planning, and offers more efficient scaling.
Nagios monitoring utilities that support the configuration-management functions of the FCAPS model
include auto discovery, automated software distribution, backup and restore, change management, copy
configuration, inventory and asset management, job initiation, tracking, execution, and remote
configuration. An example for the necessity of configuration-management would be a systems
administrator at Happy Health Systems that was making system modifications in a way which resulted
with a negative impact to the production environment. The lack of configuration-management oversight
puts the company at risk and provides no visibility to upper management on the approval process. It

leaves an accountability gap in the stakeholders SLA agreement without an audit trail or a possible
recourse for recovery. The change management module of Nagios would systemically ensure that all
change management processes were initiated, tracked, documented and executed in proper manner.
This is an important aspect of network management that helps Happy Health Systems to support their
mission statement in providing value-added health care service to its customers while ensuring the
integrity of their network infrastructure.
Accounting-management
Accounting-management is the network monitoring method at the allocation level which is
dedicated to distributing device resources optimally across a network for all users. The goal is to make
the most effective usage of network resources to provide a level of service to stakeholders at a minimal
cost. This involves the collection of network data on devices such as link utilization, memory, data
storage, and CPU processing time. Nagios monitoring utilities that support the accounting-management
functions of the FCAPS model include support for different accounting modes, service and resource
usage tracking, and usage reporting for costing purposes. An example of accounting-management
feature would be the service and resource usage tracking to monitor allocated disk storage limitations and
the MS Exchange email service quotas for all Happy Health Systems employees. Lack of proper
monitoring and management of disk storage could potently lead to slower network performance and
additional costs. This aids in organizations business objectives with better network efficiencies that utilize
existing disk storage without the unnecessary cost expenditures for additional hardware.
Performance-management
Performance-management is the process involved with examining current network efficiency
levels, then identifying methods for improvements and applying these methods to achieve optimal
network performance. This activity includes continually monitoring the health of a network, logging data

captured through network threshold parameters, and performing trend analysis. The objective is to
maximize throughput, avoid bottlenecks, identify any potential problems and plan ahead for future
expansion, changes or upgrades to the network environment. Nagios monitoring utilities reflective of
performance-management functions of the FCAPS model include capacity planning, consistency with
performance levels, data collection, monitoring, analysis, report generation, problem reporting, network
utilization and error rates. An example of performance-management using Nagios would be
implementing effective performance counter monitoring on objects such as CPU processor time, memory
utilization, disk I/O, and NIC network traffic. The benefits of counter monitoring aids in capacity planning
and trend information for future upgrades, increased application availability, server services, rapid
detection of network outages, failures with protocols, services, processes and batch jobs. Happy Health
Systems could use performance counter monitoring to baseline the new EMR – Electronic Medical
Record system to ensure performance levels meet the requirements set forth in the SLA with the
stakeholders. The EPIC Electronic Health Record, Phillips I-Site Radiology System and the Cerner
Pathnet Laboratory systems could be base lined for comparison using performance counters. This
information would benefit the business needs for Happy Health Systems in the final selection for the
clinical application.
Security-management
Security-management is the protection process concerned with monitoring for unauthorized
network intrusions, controlling network access, and securing data. Provisions and policies are
implemented by network administrators and monitored for the prevention of unauthorized access, misuse,
modification, or denial of service of network resources. The Nagios monitoring utilities that support the
security-management functions of the FCAPS model include access logging, authentication, encryption,
security alarm thresholds, event reporting and security intrusion detection. Security-management
benefits the Happy Health Systems organization where monitoring is distributed across a combined
centralized and distributed architecture structure with components providing continuous monitoring of

real-time events. Happy Health Systems plans to use Symantec Security Suite and Spybot Search and
Destroy as part of their security-management infrastructure. The use of these utilities improves the
overall security of data with a round-the-clock monitoring system to secure and protect company
resources.
Centralized, Distributed, and Hierarchical Management
Centralized management is the process where all management data such as SNMP, pings, trace
route, polling and responses, radiate from a single management system (McCabe, Network Analysis,
Architecture, and Design, 2007). The flows of management data behave in a similar fashion like the
traffic flows of a client-server network. The advantage of centralized management is that only one
management system is required and the day-to-day operating costs to monitor the network are reduced.
In a distributed management model multiple various components are strategically placed across
the network for monitoring purposes. Each local management system is used to distribute the
management functions across interconnected domains. Advantages of distributed managements
systems are monitoring devices that collect data locally and the reduced amount of management data
transmitted across the network. Another benefit this model offers is redundancy within the network in the
event of other monitoring device failures. The trade-off to the distributed management model would be
the cost associated with the additional number of monitoring devices or management systems required.
Happy Health Systems is a combination of a centralized and distributed infrastructure which would be
well suited for a distributed management model where monitoring is distributed across the network. This
model would benefit the business needs for Happy Health Systems while providing a cost effective
solution.
A hierarchical management model spans multiple platforms and separates management into
distinct functions. It is well suited for large enterprise networks or organizations with specialized
requirements for collecting management data. Localized monitoring devices can collect management
data and then pass the information directly to displays or storage devices where the data is processed

(McCabe, Network Analysis, Architecture, and Design, 2007). Filters can be configured to send only
relevant data such as counters or incremental event updates across the network. Advantages of
hierarchical management include reduction of the amount of data transmitted across the network,
independent component functionality with redundancy, and configurations that can be tailored to the
specific needs of a network. The drawback to hierarchical management is the complexity and costs
overhead required with multiply management components on a network.
Network Management Structure
The diagram in figure 48 illustrates the Happy Health Systems network management architecture
structure proposal and depicts the locations where each management function resides in the network.
The main network management system resides at the centralized IT office location in the Kansas City
Hospital facility. Each Hospital and the research facility have local monitoring node devices that collect
data within their respective local domains. Management traffic flows between the local monitoring nodes
and the network management system located in Kansas City. The local monitoring node systems are
configured to provide redundant monitoring of other monitoring nodes in the event of a device failure
within the network.

Figure 48

Performance Management Architecture
The quintessence aspect of performance management architecture consists of determining which
performance mechanisms are applicable to the specific needs of a network. The elements of
performance architecture mechanisms include quality of service, prioritization, scheduling, traffic
conditioning, SLA – service level agreements, and policies (McCabe, Network Analysis, Architecture, and
Design, 2007). In part, the determination where each of these mechanism elements will be applied is
based around the FCAPS management framework model used in conjunction with the Nagios network
and infrastructure monitoring software application. Following FCAPS guidelines is the recommended
methodology approach for the Happy Health Systems organization in achieving the objectives for their
performance management architecture. This document will present strategies for the Happy Health
System organization to meet their business needs of performance management within the FCAPS
framework model. It will provide specifications for required performance mechanisms, where
performance mechanisms will be applied, and the performance relationships of components between and
within the network architecture structure.
Happy Health Systems Business Needs
Happy Health Systems is a health care organization that plans to implement a common electronic
medical record (EMR) system that will be used throughout their organization by all facilities covering a
three-state area. In addition to the EMR system, they have made a decision to implement MS Exchange
e-mail, Microsoft Office Suite, PeopleSoft ERP (finance, supply chain, HR and Payroll modules),
Symantec Security Suite, and Spybot Search and Destroy applications. The board of directors and senior
managers are willing to pay the necessary IT staff costs for implementing and supporting performance
mechanisms which include quality of service, SLA – service level agreements, and policies. Senior
management has requested SLA documentation to address the performance architecture that will meet
the business needs of the organization. According to McCabe, there are two common ways to apply

SLAs to a network (McCabe, 2007). One type of service level agreement is between the IT group
(typically internal) and the organizations customers they serve. The other type of service level agreement
would be external to the company organization, such as a third-party service provider that maintains the
WAN for the network.
Service Level Agreements
The Service Level Agreements will address the following definitions of performance mechanisms
and include a set of activities for the Happy Health Systems network. Each SLA element will contain a
description for the appropriate level of service in a comprehensive format so that each party is in
agreement of the process to be accomplished.
 Improvement of overall performance of the Happy Health Systems network
 Improving performance to EMR user groups and medical devices
 Changing the Happy Health Systems network from a cost center to profitability
 Merging multiple traffic types over the Happy Health Systems network infrastructure
 Differentiating EMR customers for multiple levels of service
 Addressing ethical standards while meeting the goals of the SLA
 Provide external SLA for WAN support through third-party service provider
Improvement of overall performance of the Happy Health Systems network
Based upon data gathered during the requirements phase, the ten clinics and research facility will
be scoped with a single-tier level of performance where data traffic must have a measured availability
(RMA) of 97% and a flow of 1.5 Mbits per second. The hospitals and physician practice will be assigned
a multi-tier performance level with mechanisms to provide means of identifying traffic flow types.

Implementing a Common EMR and Network Architecture for Happy Health Systems

Implementing a Common EMR and Network Architecture for Happy Health Systems

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to Implementing a Common EMR and Network Architecture for Happy Health Systems

Similar to Implementing a Common EMR and Network Architecture for Happy Health Systems (20)

Implementing a Common EMR and Network Architecture for Happy Health Systems