My capstone project is to recommend a Windows networked environment to facilitate the remote monitoring of neuro-surgeries. As a consultant I was approached by XYZ-Monitoring to assist in the design of a network from the ground up that would support the remote monitoring of neuro-surgeries using Cadwell Laboratories’ Cascade system.
XYZ-Monitoring (herein referred to as XYZ) wanted a Windows network that would be integrated with their existing Cisco ASA firewall device. XYZ wanted to use a virtualized environment because they had a limited budget for new hardware. They needed a secure solution that would meet HIPAA requirement concerning the security of patient data. XYZ requires all users to connect to their environment through a VPN connection bound to the Cisco ASA firewall. They have three user groups that will need to have access to the environment; however, they have multiple clients that need to remain separated when connected to the network.
Given these requirements by XYZ, it was clear they wanted an Active Directory integrated environment so that users would be grouped by job function and by client. XYZ would need at least three high level Organizational Units (OUs), one for each job function; they would also potentially need an OU for each client. They would need Group Policy Objects (GPOs) to provide ease of administration once the design was complete as well as provide access policies to the environment based on job function.
Provided with these requirements, background information and expectations of XYZ, it was obvious that a multiphase approach to the project was required. We divided the project into logical phases as follows:
• A design phase where the physical network will be defined as well as the server environment using Microsoft’s suggested best practices for physical and virtual machines. The Active Directory Domain will be laid out here as well.
• A testing phase where various hyper-visors, the underlying system that manages virtual machines, will be tested. Different solutions for the actual remote monitoring will be explored including Remote Desktop Services (RDS) and Virtual Desktop Infrastructure (VDI).
• An implementation phase where the Active Directory environment will be integrated with the hardware firewall using RADIUS and the NPS (Network Policy Server) under the Network Policy and Access Services server role. The VDI or RDS solution that has been determined to be the best solution for XYZ’s needs will also be developed. All GPO’s that were tested and found to meet their requirements for access will be linked to their respective OUs.
• A deployment phase where all deliverables will be transferred to XYZ as well as instructions on how to continue to administer the environment when new clients need to be added. Best practice instructions for the creation of new OUs and GPOs will also be provided so that XYZ will be able to expand the services they offer.
Each phase will be marked by milestones and be associated with a timeline to mark these milestones. The overall timeline for the project was four months, but XYZ had set aside six months for the development and deployment of their Windows environment. XYZ’s business in a very niche market, but they have plans for expansion into other areas of monitoring as well. Knowing the business goals for XYZ was crucial in developing an environment that would be scalable for their future needs. Using a virtualized environment for XYZ allows for adding additional servers while keeping the hardware costs to a minimum. While there are best practices for how many virtual machines a hyper-visor can manage, which is based on the underlying architecture of the hyper-visor and only varies slightly from hyper-visor to hyper-visor, if the physical servers are practically identical they can be clustered together to keep the environment functional in the event of a hardware failure. Using Cadwell Laboratories’ Cascade system will allow for remote monitoring of other surgeries as well as certain clinical studies. For remote monitoring all Cascade requires to connect is the IP (Internet Protocol) address of the remote system (Cadwell Laboratories, 2009). This will potentially open the door for XYZ to provide monitoring for any study or surgery that can be connected to the Cascade system. The Windows environment designed for XYZ around Active Directory allows for their network to expand as needed based on AD DS (Active Directory Domain Services) ability to add additional domain controllers, domain users and computers, and even replication of the Active Directory database to remote offices over an internet connection. If XYZ finds that customers are having latency issues, which will affect the real time need of the monitoring, they can open another office nearer to their clients and have those clients authenticate to systems in the new site. All of these items were including in the planning of the XYZ environment. With the potential for growth in the market of remote monitoring, XYZ needed a solution that could expand and expand rapidly as the need arises. That was the goal of this Windows network design for XYZ-Monitoring, to provide an environment that was scalable to the company’s needs as the need for remote monitoring without using a screen sharing solution continues to grow in the market.
As stated at the beginning of this project, XYZ wanted a solution that provided remote monitoring of neuro-surgeries without using a screen sharing program. This suggests that other companies that provide remote monitoring of neuro-surgeries must be using a screen sharing program. This review will discuss what screen sharing is and why a solution that does not use screen sharing would be providing a superior product to those clients that monitor neuro-surgeries. At its most basic screen sharing is the sharing of the desktop or a program with one or more others who are using another computer. That is, two users are sharing the same screen and resources from one computer on one or more other computers; the drawback of this model is that only one person can be in control of the shared content at a time. If two users need to check different items they would have to take turns, first one making a modification then another making their modification. Examining screen sharing further finds that there is very little latency involved with this type of monitoring solution as each user is experiencing the exact same thing at the same time. One user moves his or her mouse and everyone sees the pointer move across the screen. This near real time view with screen sharing is what makes it an attractive option for many different businesses not just those involved in the remote monitoring of neuro-surgeries. The reason that latency is such an important factor is that if there is any delay in the monitoring during a surgery, the monitoring physician may miss a crucial item as their session catches up to the real time display of the surgery technicians. To reduce or eliminate latency is the key factor for any solution in the monitoring of neuro-surgeries. Many products offer this reduced or eliminated latency in their screen sharing products. One example of a screen sharing option is LogMeIn. XYZ has uses LogMeIn so that they could provide technical support to their clients using a remote computer. LogMeIn provides “remote access to your desktop so you can open files, check your email, run programs, and stay productive from your mobile device or any computer over the Internet” (www.logmein.com). This screen sharing is exactly what it appears to be, the monitoring physician and the surgery technician see the exact same thing, with only one of them being able to control the resources of the monitoring computer at a time. If the monitoring physician wants to check something, they must take control of the surgery technician’s screen and scroll back to whatever it was they wanted to check. This may provide its own difficulties if the surgery technician also wanted to check something on a different monitor at the same time as only one person can be in control at a time with screen sharing. Another example of a popular screen sharing program is GoToMeeting. This product also provides the real time sharing of content over an internet connection. GotoMeeting allows for one person to invite any number of other users to view their shared content (www.gotomeeting.com). This sharing has the same drawbacks as any other screen sharing program as it only allows for control of the content by one user at a time. The ease in which screen sharing can be implemented makes it an extremely attractive solution, all that is needed is a connection to the internet and an invitation from the person doing the sharing. The issue arises with the inability to control what is on the screen by multiple users at the same time. While this may be convenient during a meeting where one person is sharing content with one or more other people, it has certain drawbacks during any type of surgery monitoring where someone may need to double check an item that appeared to be out of normal for that proceeding. The other alternative would be to put a monitoring physician in the operating room during the surgery, which of course has its own set of concerns. One of which is a monitoring physician is then capable of monitoring only one surgery at a time and must be on site during the surgery. This would add untoward expense to the surgery for the patient, as they would be paying two physicians to be present during the entire procedure. The advantage of having a monitoring physician in the operating room is of course having another expert immediately available for consultation during the surgery. However, for many hospitals this is not a practical solution do to staffing constraints or the availability of qualified physicians in a given location. This is why XYZ wanted to offer a solution that did not use screen sharing; they wanted to offer the monitoring physician the ability to check something without inhibiting the surgery tech from checking something else at the same time. The use of Cadwell’s Cascade system allows for just that. Cascade allows for the remote monitoring of a surgery by IP address (Cadwell Laboratories, 2009). All the monitoring physician needs is the IP of the surgery technician’s session and they can independently monitor the same surgery. If the monitoring physician wants to check something, they are not taking control of the surgery technician’s screen to do so.
XYZ had specific business and technical requirements. Their business requirements were simple: minimize the cost of hardware and software, and design a solution that allows the company to grow its client base. Their technical requirements were a bit more involved. The technical requirements were as follows:
• Use the Cisco ASA firewall to provide a VPN (virtual private network) solution, minimizing the number of times a user needs to enter a password to reach the environment.
• Prevent specific users from authenticate to the VPN while preventing them from accessing resources on the network.
• Prevent different clients from knowing who else is on the network.
• Allow only monitoring physicians access to the VDI or RDS solution.
• Allow managers to reset the passwords for only their employees.
• Provide a high availability solution so that users can authenticate to the VPN if one server fails.
With these goals in mind, it was time to design and test a solution that would fit the needs of XYZ. The first item that needed to be considered was what kind and how many servers XYZ was going to need. Knowing they wanted to use a VPN solution through their ASA firewall and they had specific requirements for user authentication and user rights, an NPS (Network Policy Server) server was needed. To authenticate users through the Cisco ASA, it was determined that a RADIUS server was needed, as this is a sub-function of NPS these roles and functions could be combined. To minimize the number of passwords a user needed to input, it was determined that an Active Directory integrated environment would be best suited to meet XYZ’s needs. The NPS server would use Active Directory to authenticate users. This meant that XYZ needed at least one domain controller and DNS server. As these functions are combined when you perform the dcpromo.exe command that would require another server. Because XYZ wants to use a virtualized environment, there are suggested best practices for deploying domain controllers, the quickest way to determine these is to use the “Best Practice Analyzer” (AD DS, 2010). Using an Active Directory environment allows for the administration of the domain from a central location. That is the administrator can make changes to Active Directory without having to be physically consoled to the server. By using multiple domain controllers, XYZ is able to make changes on one and not affect any currently connected network users. These changes will then be replicated to the other domain controllers in the domain at a given interval. These domain chances can be forced by using the replicate now option in Active Directory Sites and Services under Administrative Tools from the Start Menu on one of the domain controllers. By using the NPS server role XYZ can make their access policies more granular. That is they are able to limit the time logons are allowed for specific users to specific times during the day. They can define specific users access to very specific network resources. Using NPS XYZ can also require computers connecting to the network to be up to date with regards to the latest security updates from Microsoft as well as require an active virus protection before being allowed access to the network. By using RADIUS for authentication XYZ can provide better network protection by using CHAPv2 over a less secure authentication methods such as PAP (Planning NPS, 2008). Using CHAPv2 provides better encryption of data over they network by requiring a double handshake, that is each computer must announce itself and confirm its identity before the secure connection is made. XYZ also required a virtual desktop solution for the monitoring physicians, depending on how this was implemented would define how many additional servers would be needed. To determine the best virtualization solution for XYZ’s needs, we tested different hyper-visors. The first tested was Citrix’s XenServer, which had difficulties supporting the Cascade program, which is the main program that will be used by the monitoring physician, so this solution would not work. The next hyper-visor that was tested was VMware’s ESXi, which met the requirements beautifully. From the business requirement of keeping software cost minimized, ESXi is free. ESXi’s hardware requirements are similar to Windows Hyper-V in that 2GB of RAM is recommended for the hyper-visor; it supports many different guest operating systems and runs on 64-bit hardware (VMware KB: Minimum, 2011). Windows Hyper-V was tested as well, and it too met most of the requirements of XYZ, such as running on 64-bit hardware, supporting many different guest operating systems and having a recommendation of at least 2GB of RAM (About Virtual Machines, 2011). However, in the end ESXi with its free cost because the clear choice for XYZ. At this point in became apparent that the best solution would be to deploy two hardware servers that could operate a varying number of virtual machines. With the hardware requirements for the hyper-visor known it was time to recommend a specific server to meet the needs of XYZ. The recommendation was to use DELL R710 servers with two 2.4GHZ processors, 32GB of RAM and redundant power supplies. These hardware specifications give the ability to add multiple virtual machines to each of the physical servers within the specifications of the hyper-visor, without over taxing the system, thereby hindering performance. The reason for using two servers was they could be set up in a failover type cluster, so that if one physical server failed, the environment would stay up. This failover cluster is known as fault tolerance in the ESXi world, there are specific requirements to providing fault tolerance in ESXi, including the hardware of the servers and the guest operating system (VMware KB: Processors, 2012).
Goals and Objectives
XYZ had some very specific technical and business goals. The business goals were straightforward; minimize the cost of hardware and software. These goals were partially achieved by using VMware’s ESXi hyper-visor, as it is a free solution. The hardware requirements were met by suing the two Dell r710 servers. These servers have a base price of around $1600.00 and are completely customizable (www.dell.com ). The objective of this hardware solution was to provide some redundancy and failover options. The redundancy was provided by using a RAID 10 configuration, which is data mirroring with data striping. Using two servers in a fault tolerant allows for failover if one server should fail, thereby keeping the network operational even in the event of one physical server going down. The technical requirements were a bit more involved, but included:
• An Active Directory integrated environment.
• A VPN solution using RADIUS to authenticate users
• Allow surgery technicians to authenticate but not access any other network resources.
• Allow monitoring physicians access to Cascade and select other network resources.
• Allow managers to reset passwords only for their employees.
• Deny the ability for any client to see any other client on the network.
• Be HIPAA compliant concerning the security of patient data on the network.
Knowing the goals of XYZ it was time to determine how to meet these goals. Meeting the business goals of XYZ was the first priority. As stated previously these goals were minimize the cost of hardware and software. To help achieve the goal of minimizing hardware cost we needed to examine exactly what XYZ wanted to accomplish, so that hardware recommendations could be made based on their current needs yet still be scalable as their business grows. Using a virtualized environment allows XYZ to run many servers and workstations on fewer physical machines. This virtualization was the primary solution to the goal to minimize hardware cost.
To minimize software cost we had to determine, using Microsoft’s Best Practice Analyzer, exactly which servers roles could be combined on a particular virtual machine. We also had to analyze any free versions of commercial software that might fit XYZ’s needs. The only free option for XYZ was VMware’s ESXi hyper-visor. This makes it possible to run multiple virtual machines with various roles further reducing the cost of software. To keep software costs as low as possible it was recommended to combine sever roles such as domain controller, DNS server and NPS server on one virtual machine. This reduced the number of Windows’ licenses that XYZ needed to purchase.
The technical goals for XYZ were achieved one by one. It was decided to take a systematic approach to the technical goals, which would allow for testing each service as it was added to the servers.
The first item addressed for XYZ’s technical goals was setting up AD DS (Active Directory Directory Services) on a domain controller for XYZ. This allows all other servers to belong to the same domain, it allows for the creation of Organizational Units (OUs) for the domain and allows for the separation of XYZ’s clients by sub-netting the environment. Microsoft recommends using at least two domain controllers in a domain, to provide user and computer authentication in the event that one domain controller fails (About Virtual Machines, 2011). The creation of the Active Directory domain was straight forward; install the AD DS role services on a server, run dcpromo.exe at the end of the installation and Active Directory is up and running. To verify the domain controller was working correctly we created test user accounts and used these to log on to the domain.
After AD DS was configured, the NPS role was added to one of the domain controllers to provide network level access policies for the environment; this is where RADIUS was configured to authenticate the VPN users set up on the Cisco ASA firewall. This proved to have some difficulties at first because the CHAPv2 authentication was not configured correctly. This was corrected by first re-installing RADIUS on the server and then on the firewall using the same secret pass phrase on both the server and the firewall. This also provided HIPAA compliance concerning the security of patient data on the network because all data is travelling over a secure VPN tunnel.
Creating the OUs to allow for specific access control based on job title was the next item on the technical requirement list. There were three main OUs created, Doctors for the monitoring physician, Managers for the manager(s) of the various clients of XYZ and Technicians for the surgery technicians. Each OU was prevented from accidental deletion as per Microsoft’s best practice recommendations (AD DS:, 2010). The next item was to create Group Policy Objects (GPOs) linked to the various OUs to provide the required security to the network; GPOs were used to prevent any client from seeing who was on the main network even though each client would be in its own subnet. This was done more for added security then for necessity.
To expand on how this was accomplished, after creating the OUs we needed to make sure that users from each OU had the correct permissions. Starting with Technician OU we denied these users access to all network resources. XYZ only wanted technicians to be able to access the VPN for purposes of assigning them an IP address because Cascade uses IP addresses to connect a remote session (Cadwell, 2009).
Once the Technician OU was prevented from accessing other network resources we provisioned the Doctor OU, which needed users to be able to connect to a virtual workstation running Windows 7 with the Cascade program installed. The determination to use virtual workstations is described in detail below. However, these users also needed to be prevented from viewing the Active Directory environment because no two clients of XYZ should be able to see each other on the network. This part of the goal was achieved by making changes on the workstations. If a workstation is joined to an Active Directory domain by default it can browse the domain. This setting needs to be changed in the registry of the workstation. Once the registry was edited on the workstations, XYZ was confident we had provided the required security for the Doctor OU.
The final OU that needed to be configured was the Manager OU, this was identical to the Doctor OU except it needed the added ability to reset passwords for users without the managers company. While implementing the Manager OU, XYZ asked if it were possible to also allow managers the ability to add and remove users within the manager’s specific company. This was accomplished by the delegation of limited administrative rights to this OU. This ensured that managers still had the ability to be the first line of administration for their company.
The next objective was to determine the best way for monitoring physicians to connect to Cadwell’s Cascade. RDS (Remote Desktop Services) was explored, but lacked the functionality required by XYZ for future expansion of offered services. The solution was to create a virtual machine for each monitoring physician. These machines were to be configured with Windows 7 and the Cascade program. XYZ felt that giving each monitoring physician their own VM was the best solution for their needs. These Windows 7 machines were configured based on the needs of individual clients. This flexibility allows XYZ to offer more services such as a secure file share for those clients that would like that service. Each Windows 7 virtual workstation used local GPOs to prevent the exploration of the network and Active Directory environment by any monitoring physician. The Cascade program was configured to use only the IP range of the individual client to further prevent the accidental location of another client on the network.
Project Timeline (Appendix 2)
At the beginning of this project, XYZ asked me to assist in the design of their environment. One of the first items discussed was the time frame for the project. XYZ had an expectation of a delivered product to their clients to be the beginning of 2012. We originally met at the beginning of July 2011 so this meant a timeline of six months. This included a limited deployment to clients to work out any unexpected issue that may not have been addressed during the design and implementation of XYZ’s Windows networked environment.
It was determined during the initial design meeting to have a timeline of approximately four months. During these meetings we decided on clear milestones to mark progress and clear expectations on when these milestones would be met. For the most part these milestones were met within their expected time frames, however, there were a couple of items that missed the mark. The two items that went past the original expectations were configuring RADIUS and the implementation of the Doctor OU. While we were able to get RADIUS configured for VPN authentication, it did not use the more secure CHAPv2 authentication. Getting RADIUS to work correctly with CHAPv2 required a couple of extra days. These extra days were spent researching and testing various solutions to ensure CHAPv2 was being used instead of the less secure PAP authentication.
The Doctor OU was a bit more difficult because it had so many technical requirements associated with it. This was the OU that required access to specific network resources, denying access to see other clients on the network, preventing browsing of the Active Directory domain and ensuring the security of patient data as required by HIPPA. This OU’s implementation was a lot more work than originally anticipated. In the end it went almost two weeks pas the original plan, however once all of the requirements for this OU were accomplished there were ported directly over to the Manager OU which brought us closer to the original timeline.
With all the testing required and the setbacks experienced, XYZ was still able to deploy their environment in early November. This gave them adequate time for their planned limited deployment before the first of the year. During the limited deployment, XYZ did not report any problems with their remote monitoring solution. In fact, they were singing its praises as they observed surgery after surgery with very little latency from end to end.
Project Development
As stated previously the entire goal of this project was to design a Windows networked environment that would facilitate the remote monitoring of neuro-surgeries without using a screen sharing solution. This was accomplished by providing an Active Directory integrated environment over a VPN network that uses RADIUS and CHAPv2 to authenticate users. XYZ uses a VPN to provide a controlled IP space to ensure Cascade’s remote monitoring feature can be fully utilized.
The problems encountered during this project and their solutions have been described in detail above. This will be a brief over view of those problems and their resolutions. One of the biggest problems encountered was the difficulty with RADIUS and CHAPv2 authentication. While RADIUS configuration was straight forward, it was only using PAP for authentication. The resolution to this problem was to re-install RADIUS and configure the settings first on the server and then on the firewall. When it was configured first on the firewall and then on server, RADIUS would default to PAP authentication. This added a couple of days of research to the project, that fell outside of the original plan, but did not change the overall plan of the project.
The other real problem that was encountered was the implementation of the Doctor OU. This problem was not really a problem with the Doctor OU, but with what network resources could be viewed by a doctor logged on to the network. The solution to this was to edit the registry of the workstations the doctors would use to monitor surgeries. This all occurred during the implementation of the Doctor OU so has been discussed in detail when describing that particular implementation.
The only real unexpected requirement came when XYZ asked for managers to have more control of the users in their particular monitoring company. This was resolved by simply delegating limited administrative rights to the Manager OU. With the granularity provided by NPS and GPOs this was a very simple request and easily added to the project for XYZ.
The actual effect of this project was providing a non-screen sharing solution for the remote monitoring of neuro-surgeries. This was the goal all along. XYZ is currently using this solution to provide their clients with a better alternative to screen sharing during the monitoring of neuro-surgeries. A side effect to this project was that the XYZ administrator learned a lot about Active Directory and GPOs so that he can continue to administer their environment as XYZ continues to grow.
Over all this project was a success. The project came in under budget, on time and works as expected. XYZ has a remote monitoring solution that does not require screen sharing. While there were hurdles to overcome during the project, these hurdles were not so high as to be insurmountable. As the project progressed, not only did the XYZ administrator learn more about Microsoft’s products, but I too was able to learn a few idiosyncrasies of how Microsoft networks are designed and implemented.
Project Deliverables
The deliverables for XYZ were items that were not just physical objects, but logical objects represented by the design of their Windows environment from the ground up. These included:
• The Active Directory diagram
• RADIUS authentication for XYZ’s VPN solution
• The remote environment for monitoring physicians
• A HIPAA compliant environment Following is an outline of the logical deliverables. These outlines are based on the actual deliverable, which cannot be depicted here, only described. Each deliverable is broken down as to what was expected by XYZ and how it was implemented, for example the HIPAA compliance requirement will be described, but cannot be shown here as a deliverable. The Active Directory diagram will be included in Appendix 3. To set up RADIUS authentication for the VPN solution the first item that was needed was to add the NPS server role to a server. This is done by first adding the Network Policy and Access Services role to a domain controller. The NPS role is the only role that can be added when making this change, no other sub-roles should be added at this time as it may cause conflicts and Windows Server will give you this warning (Planning NPS, 2008). Once this role is installed, you then configure it using the Network Policy Server snap-in under Administrative Tools. The next step is to add a new RADIUS client, this will pair with RADIUS on the Cisco ASA. Once this process is finished, users will authenticate against RADIUS for network level access. The remote environment for monitoring physicians was implemented by providing a remote workstation for each physician. That is, a virtual machine was created for each monitoring physician on XYZ’s network that uses Windows 7. These VMs were locked down so that physicians could not browse the network or see any Active Directory items by using local GPOs and registry edits. They amount of virtual disk space for each of these VMs was limited to 10GB, this helps prevent the storage of any patient data on the VM. These VMs were also designed so that they can only be reached through XYZ’s VPN. This further protects any latent patient data as only authorized users can connect to the VPN. Each workstation was configured for only one user, with a standard account and of course the XYZ administrator. Using GPOs these workstations were further limited in the programs available to the monitoring physician, as well as preventing them from downloading and installing any new programs to the workstation. The GPOs were configured on the domain controllers for the network level protection as well as locally for local protection. The local GPOs were used to lock down components of the workstation such as the accessibility of the Control Panel and Network Places from the start menu and any from the preview pane in any open window. The network level GPOs were configured to limit access to the workstations. By tying these workstations to specific user accounts, XYZ is preventing the accidental copying of patient data to unauthorized sources. This is one of the major components of HIPAA compliance; the protection of patient data. All of the workstations and servers were further protected by using Windows BitLocker feature, which encrypts the hard drive of the machine (BitLocker, 2012). With regards to HIPAA compliance, the main point here is the protect patient data. HIPAA states:
“The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required the Secretary of the U.S. Department of Health and Human Services (HHS) to develop regulations protecting the privacy and security of certain health information.1 To fulfill this requirement, HHS published what are commonly known as the HIPAA Privacy Rule and the HIPAA Security Rule. The Privacy Rule, or Standards for Privacy of Individually Identifiable Health Information, establishes national standards for the protection of certain health information. The Security Standards for the Protection of Electronic Protected Health Information (the Security Rule) establish a national set of security standards for protecting certain health information that is held or transferred in electronic form. The Security Rule operationalizes the protections contained in the Privacy Rule by addressing the technical and non-technical safeguards that organizations called “covered entities” must put in place to secure individuals’ “electronic protected health information” (e-PHI). Within HHS, the Office for Civil Rights (OCR) has responsibility for enforcing the Privacy and Security Rules with voluntary compliance activities and civil money penalties” (Summary of HIPAA, n.d.)
This is further detailed in the HIPAA technical requirements as well:
“Access Control. A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information (e-PHI).24
Audit Controls. A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use e-PHI.25
Integrity Controls. A covered entity must implement policies and procedures to ensure that e-PHI is not improperly altered or destroyed. Electronic measures must be put in place to confirm that e-PHI has not been improperly altered or destroyed.26
Transmission Security. A covered entity must implement technical security measures that guard against unauthorized access to e-PHI that is being transmitted over an electronic network.” (Summary of HIPAA, n.d.)
The main points that XYZ needed to cover was “Access Control” and “Transmission Security” as they do not intend to store any patient data in their environment, but do transport this data across their network. The “Access Control” and “Transmission Security” are both covered by the VPN solution that uses RADIUS for authentication to the network.