hardware and infrastructure suggested best … and...client hardware and infrastructure suggested...
TRANSCRIPT
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Client Hardware and Infrastructure Suggested Best Practices
While it is the responsibility of our Clients to support their hardware and infrastructure, the Pretty Good Practices
below are provided for informational purposes (see the ReDoc Service Level Agreement for details). The intent of
this document is to help our Clients understand some of the key areas for infrastructure planning, installation,
configuration, monitoring, maintenance, upgrading, and budgeting for equipment lifecycles. Note that if ReDoc
provides support for an issue caused by a lack of infrastructure maintenance or poor design, it will be on a time
and materials basis.
Well thought out and thoroughly monitored IT practices lead to good system performance and minimal down-time
and, once established, do not require significant time or expense to maintain. Inattention to the subjects below,
on the other hand, can result in a variety of serious problems ranging from sub-optimal system performance
(slowness) to system ‘crashes’ with loss of data. Given the total overall investment you have made in your ReDoc
system and the total benefits realized, the time and costs associated with effective preventive maintenance are
very modest relative to the value they deliver.
For example, one of the single leading causes of downtime for ReDoc clients is running out of hard drive space and
crashing. Monitoring hard drive space as part of a weekly or monthly systems check takes minutes; truncating or
archiving transaction logs to save disk space can be an automated maintenance routine; and eventually adding an
additional hard drive can cost ~$100. One of the leading causes of poor system performance is highly fragmented
hard drives. Automating a periodic disk defragmentation and confirming the results during a weekly or monthly
systems check takes minutes. These two actions alone could save the disruption and significant loss of
productivity caused by system down time.
Most of the concepts addressed below are subjective, and our primary recommendation is that our Client’s use
their own IT staff, processes, and procedures to align their own hardware and infrastructure best practices for all
internal systems. For example, in addition to ReDoc, most of our Clients use and maintain a billing system, email,
accounting/payroll systems, basic desktop applications (like Microsoft Office), and other applications. Decisions on
topics like networking, security, server management, and backups should be consistent throughout the
organization, and must take into account all supported applications. The checkpoints below should be compared
to and used to augment your weekly, monthly, quarterly, and annual monitoring and maintenance checklists.
The Suggested Best Practices below consider only ReDoc, and are, in many cases, only one of several ways in which
basic tasks (such as backups) can be accomplished. Thus, this should not be considered a complete and
comprehensive list. If you are not familiar with the tasks below, or if you are not comfortable with developing your
own internal IT processes and procedures, we strongly urge you to seek local IT support services. If they are not
available, TRDC can provide these services on a time and materials basis, but for the reasons listed above TRDC
should be considered a vendor of last resort for IT support services.
Single User (on a single computer)
- Don’t “suspend” your computer; When you need to exit ReDoc, completely exit and shut down.
Configure your power settings to actually shut down, and not suspend. Suspending (or
sleeping/hibernating) is effectively the same as withdrawing power from your system and can cause
corruption of your ReDoc database.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
All Servers (including application, SQL, and Thin Client)
- Monitor and maintain manual or automated OS, SQL and .NET framework service pack updates
- Monitor hard drive space and project capacity utilization over time
- Periodically check redundant components (ie power supplies, network cards, RAID hard drives, etc) for fail
over preparedness. Review the cost/risk/benefit analysis of redundant components where they do not
exist. For example, a redundant network card and power supply are relatively inexpensive, and have
relatively high failure rates. A modest investment could keep the server accessible and would leave
normal work uninterrupted in the event of a failure.
- Spot check Performance Monitor for overall capacity utilization. Monitor PerfMon over time to trend
CPU, memory, disk I/O, and network traffic and review for bottlenecks
- Monitor Uninterruptable Power Supplies for battery life under no-power circumstances
- Monitor UPS or line regulator for clean power
- Defragment drives and files often enough to maintain less than 8% fragmentation
- Review physical security measures for protection of PHI
- Monitor anti-virus and other security related utilities (anti-worm, firewalls, etc) for appropriate updates
- Monitor and maintain backup routines (incremental, full, and offsite). Periodically restore from each type
of backup to ensure integrity
- Many current servers ship with monitoring and alerting tools. Check to see if such utilities are present or
available, and configure as desired.
- Periodically re-boot (complete power down for 30+ seconds)
- Reliability (‘up-time’) can be optimized with:
1. Redundant network cards.
2. Redundant power supplies.
3. Redundant hard drives in a RAID array, with the OS on either a separate drive or a separate array.
4. Monitor environmental factors (temperature and humidity) for proper levels.
- Performance can be optimized by:
1. Gigabit network connectivity.
2. Fast (10,000+ rpm) hard drives.
3. Additional memory.
Microsoft SQL Server (applies whether on a shared, dedicated, or farm server)
- Recommend MS SQL 2008 Standard edition when there are less than 10 concurrent users and not using
Terminal Services; recommend Enterprise version when using Terminal Services, when supporting
multiple instances, when doing replication, or when clustering or farming. MS SQL 2005 may be used on
existing servers with the same recommendations for Enterprise edition as stated for 2008. SQL Express
can be used for a single user, or very small multi-user environment (< 5 concurrent users). Note that SQL
Express does not come bundled with a maintenance utility.
- Monitor and maintain (archive or truncate) TempDB
- When Recovery mode is set to ‘Full’, monitor and periodically truncate and/or archive all SQL transaction
log files
- Periodically re-index and defragment indices within each SQL instance
- Ensure that virus scanning is set to allow exceptions for SQL
- Reliability (‘up-time’) can be optimized with automated, periodic maintenance plans set up in MS SQL
Maintenance plans, and monitored frequently for proper execution.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
- Performance can be optimized in an Enterprise environment (more than 15 concurrent users ) on your
SQL server by:
1. Having the OS on its own physical drive.
2. Install TempDB on a physical drive other than the drive the OS is running from (usually the c:\
drive).
3. Move the OS Swap file to a physical drive other than the OS drive.
4. Set the size of your OS swap file to be a fixed size of 50% of the server’s total RAM.
5. Move the MDF to a different physical drive than the LDF
6. If a conscious decision is made to recover from a backup only (under disaster recovery
circumstances), with the loss of the transaction log file data considered acceptable, you may set
the recovery mode to ‘simple’ rather than ‘full’, which will result in a log file of a fixed max size
and no need to truncate or archive.
Local Area, Wide Area, and Wireless Networking
- Monitor overall network utilization, including saturation, packet loss and latency assessments. Monitor
the same for server backbones, and review for redundant connections where appropriate.
- Periodically check main and redundant switches and/or wireless access points for fail over preparedness.
Identify single points of failure (ie switches and wireless access points) and install redundant hardware
based on the cost/risk/benefit analysis. A modest investment in an extra switch or wireless access point
could keep the server accessible and would leave normal work uninterrupted in the event of the loss of
one switch or wireless access point.
- Monitor and maintain firewall (hardware and/or software) and any intrusion detection or other security
related hardware and applications.
- Reliability (‘up-time’) can be optimized with:
1. Redundant network cards in all servers.
2. Redundant, corporate grade (ie Cisco or equivalent) wireless access points instead of small
office/home office (ie Linksys) class devices.
- Performance can be optimized with:
1. Gigabit throughput (network cards, switches, etc) for the wired LAN.
2. Wireless 802.11G/N network devices for wireless. Corporate grade (ie Cisco or equivalent) are
recommended over small office/home office (ie Linksys) class devices.
Thin Client
- Performance is impacted by the total number of apps supported via thin client.
- Recommend starting with a low number of users and monitoring all system performance metrics before
finalizing on a scaling plan.
- If only ReDoc is deployed via thin client, a Dual Quad Core server with 48 gig of memory is likely to
support ~40 users. A Quad Core with 16 gig of memory is likely to support ~20 users. Light use by admin
or clerical staff will require lighter memory allocation (128-256 meg), while heavy use of print preview or
wound care by clinical staff will benefit by higher memory allocation (256-512 meg).
- Ensure that all Microsoft Patches are current.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Workstation PC’s – one of the most important gains that can be realized with the ReDoc system is Point of Care
documentation; allowing the therapists to document at or near where they are treating their patients, so that
daily notes (and in some cases re-evals and discharge summaries) can be completed between patients instead of at
the end of the day or later. By doing point of care documentation, it is far less likely that treatments delivered will
go undocumented (and un-billed). To facilitate point of care documentation, the therapists will usually need
mobile PC’s (laptops or tablet PC’s) and a wireless network.
- Laptops generally offer the most flexibility, since they include keyboards. If Tablet PC’s are used,
companion keyboards are encouraged since therapy initial evaluations and, in some cases, other
documentation can include extensive free text typing.
- Extra power cords and/or batteries for laptops or tablet PC’s can significantly enhance usability.
- Desktop PC’s are generally best suited only for desktop space and often are not ideal for point of care
documentation, since they are completely immobile and take up significant space.
Printing – The ReDoc application uses the Operating System (Windows) print spooler. If printing appears to be
slow, it can be diagnosed by right clicking on the target printer in Printer Setup and selecting Properties. Any delay
experienced there contributes to the delay in printing a document from within ReDoc.
Budgeting for hardware lifecycles. As a general rule, workstations can be expected to last approximately three
years, and servers about 4-5 years. Financially, most organizations will budget for cycling out their hardware at
these intervals, but only actually purchase new equipment when absolutely necessary. That decision requires a
careful analysis of the risk of losing a single piece of hardware. For example, workstations can often be lost, and
replaced within a week or two, without significant loss of productivity. The unexpected loss of mission critical
servers may so substantially hurt productivity, that it makes financial sense to have 100% redundancy so any single
failure has a backup. In multi-server environments, some IT professionals will proactively replace and ‘retire’ or
repurpose older servers to less mission critical roles after 3-4 years and run them there until they fail beyond
repair.
Minimum System Specifications. A current copy of the Minimum System Specifications for ReDoc is available at
www.rehabdocumentation.com/hardware .
Appendix A: Performance Assessment and Troubleshooting Guide
Appendix B: Draft Hardware and Systems Preventative Maintenance Checklists (should be subordinated to the
Client’s existing IT processes and procedures, or customized based on the needs and use volume of
each Client)
Appendix C: Suggestions to assist Covered Entities with HIPAA Compliance
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Appendix A: Performance Assessment and Troubleshooting Guide
As a guide for establishing expected performance standards for the end user experience, the following guidelines
are provided:
- Load the Patient List in <4 seconds - Preview a Progress Note in <6 seconds
- Filter the Patient List in <2 seconds - Create a ReExam in <4 seconds
- Create a Progress Note in <6 seconds - Load the Patient File Menu in <2 seconds
For the purposes of determining where performance improvements might be made within the IT infrastructure, it
can help to consider what are normally the three main parts of a network; the Server Room (and all components
between the servers and the firewall or last router in that building), the Wide Area Network connecting to User
Site(s), and the User Site(s) themselves.
RouterSwitch
Wireless Access Point
Application, database,
and Thin Client Servers.
May be one or more,
depending on number
of End Users.
End User with
ReDoc Client
(Wireless)
Router Switch
End User with
ReDoc Client
(Wired)
ReDoc Client on
Either a PC or
One Server
Server Room User Site(s)
Wide Area Network
Firewall Firewall
If the user tasks described above can be executed within the response times stipulated by an end user connected
wirelessly at the User Site, then the infrastructure as a whole is sufficient in terms of hardware, bandwidth, and
latency.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
If longer than anticipated response times result, the tests should be repeated on a wired workstation (isolating the
wireless network). If response times are then within limits, the wireless network should be diagnosed and fixed. If
response times are still not within limits, then the tests should be repeated using a copy of the ReDoc Client
installed either on one of the servers or on a PC inside the server room (isolating the WAN and all components at
the User Site). If response times are within limits when tested from the server room, then the WAN should be
diagnosed for latency, bandwidth, and overall Quality of Service. If response times are not within limits inside the
server room, check CPU, memory, disk I/O, fragmentation, and networking metrics on the servers, and confirm
that database maintenance routines are being executed properly.
Performance Measurement and Troubleshooting Tools. To augment your use of normal network monitoring and
troubleshooting tools, ReDoc can collect and provide metrics from inside the ReDoc Suite application to help you
benchmark performance on your network. Beginning in September 2010, this assessment will be done once as
part of a new Client’s implementation process to validate performance prior to scheduling your initial go-live.
Reassessments (or other network troubleshooting services) may be requested at any time by the Client, but they
are not part of the Service Level Agreement and will be charged on a time and materials basis.
Below are some examples …
Applying the Patient List Filter – many Clients aggregated
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
This is an aggregate of many clients showing response times (on the x-axis) by frequency of occurrence (on the y-
axis) for Applying a new filter to the Patient List. For all instances measured for all Clients, >99% of the response
times were <1 sec. Some, however, were > 4 sec. Not all results could be shown in this one screen shot; in fact,
some response times went out as far as 39 seconds.
Applying the Patient List Filter – one Client
This is an example of the same metric - response times for Applying the Patient List Filter – but at just one Client. It
illustrates that the vast majority of all instances of this event had response times of < 1 sec, which is as expected.
However, a notable number of instances longer than 2 sec, and ranging up to almost 26 seconds, indicates
significant variation in response time over this network. Comparing this individual Client’s response time to all
Clients seems to indicate that this one Client is the source for most, if not all of the response times above 1-2
seconds in the all Clients view. This would merit further troubleshooting by this Client to examine latency and
possibly routing or other factors that could cause such a significant variation in response times over their network.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Accurately diagramming your Network. One of the most valuable things you can do to help ensure accurate
execution of your network infrastructure planning, and later evolving or troubleshooting that network, is to create
an accurate and detailed network schematic. This should include details such as Server names, OS versions,
domain organization, router/switch/WAP make and model numbers, etc.
DeltaComm Data only T1
1.544
100 bt
100bt
1 gigbt1 gigbt
4 Cisco 9876 802.11N WAP’s with
80% overlapping coverage zones
16 Mobile users on Dell
Latitude laptops running TS Client
with .11n wireless cards
Juniper M7i
GigBT RouterCisco 1234 24 port GigBT
Switches (A and B)
8 Desktop Users
running TS Client
with 100mBT NIC’s
West Side Office
Barracuda 300n
Spam/AV/IntDect
Appliance
Portion of a Sample Network Diagram
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Appendix B: Draft Hardware and Systems Preventative Maintenance Checklists
(should be subordinated to the Client’s existing IT processes and procedures, or customized based on the needs
and use volume of each Client)
Initial Setup (either during a ReDoc implementation, or at the initial creation of a Preventative
Maintenance Plan)
Managing hardware lifecycles.
• Compare existing server and network hardware to minimum and recommended system
specifications;
� Identify existing hardware that can be applied to ReDoc tasks
� Assess and advise on the cost/benefit of hardware enhancements for performance or
reliability
� Propose new hardware acquisition where necessary
� Project hardware lifespan for server and network components
All Servers (including application, SQL, and Thin Client)
• Assess the current version of the Operating System for service pack currency and growth
potential. If Windows Server 2003 is in use, establish a plan to update to 2008 before Microsoft
sunsets 2003.
• Determine and configure for OS and .NET framework service pack updates for automated or
manual
• Establish an automated maintenance plan for:
� Monitor hard drive space and alert for pending shortfalls. Project capacity utilization over
time
� Defragmenting drives and files weekly
� Daily incremental (ReDoc app, ReLeaf Directories, etc) and weekly full backups
• Check redundant components (ie power supplies, network cards, RAID hard drives, etc) for fail
over preparedness.
• Spot check Performance Monitor for overall capacity utilization. Trend CPU, memory, disk I/O,
and network traffic over an average work day and review for bottlenecks
• Check Uninterruptable Power Supplies for battery life under no-power circumstances
• Check UPS or line regulator for clean power
• Review physical security measures for protection of PHI
• Check Storage and Hardware backup plans (for more detail on suggested Backup Plans, see the
Minimum Systems Specifications at www.rehabdocumentation.com/hardware )
• Check anti-virus and other security related utilities (anti-worm, firewalls, etc) for appropriate
updates
• Periodically re-boot (complete power down for 30+ seconds).
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Microsoft SQL Server
• Assess the current version of SQL for service pack currency and growth potential. If SQL 2005
Standard or Enterprise Edition are in use, establish a plan to update to 2008 before Microsoft
sunsets 2005.
• Determine and configure for SQL service pack updates for automated or manual
• Determine whether Recovery mode will be set to „Full‟ or „Simple‟
• Establish an automated maintenance plan for;
� Daily incremental and weekly full backups (for more detail on Backup Plans, see the Minimum
Systems Specifications at www.rehabdocumentation.com/hardware )
� Archiving truncating TempDB
� If recovery mode is set to „Full‟, monitor and periodically truncate and/or archive all SQL
transaction log files
� Re-index daily
� Defragment indicies weekly
• Ensure that virus scanning is set to allow exceptions for SQL
• Server hardware permitting, evaluate the following steps for potential performance
enhancement:
� Having the OS on its own physical drive.
� Install TempDB on a physical drive other than the drive the OS is running from (usually the
c:\ drive).
� Move the OS Swap file to a physical drive other than the OS drive.
� Set the size of your OS swap file to be a fixed size of 50% of the server‟s total RAM.
� Move the MDF to a different physical drive than the LDF
� If a conscious decision is made to recover from a backup only (under disaster recovery
circumstances), with the loss of the transaction log file data considered acceptable, you may
set the recovery mode to “simple” rather than “full”, which will result in a log file of a fixed
max size and no need to truncate or archive.
Local Area, Wide Area, and Wireless Networking
• Assess network for bottlenecks (ie low bandwidth NIC‟s, hubs, or switches)
• Monitor overall network utilization, including saturation, packet loss and latency assessments.
Monitor the same for server backbones, and review for redundant connections where
appropriate.
• Check main and redundant switches and/or wireless access points for fail over preparedness.
• Identify single points of failure (ie switches and wireless access points) and install redundant
hardware based on the cost/risk/benefit analysis. A modest investment in an extra switch or
wireless access point could keep the server accessible and would leave normal work
uninterrupted in the event of a most failures.
• Monitor and maintain firewall (hardware and/or software) and any intrusion detection or other
security related hardware and applications. Check the Firewall for appropriate port status
(open/not).
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Thin Client
• Monitor initial use (first three weeks) of different types of users to access memory allocations
� Overall server performance (memory, CPU, network bandwidth, and disk I/O)
� Memory allocation for admin or clerical staff (initial settings likely to be 128-256 meg)
� Memory allocation for heavy use of print preview or wound care by clinical staff (initial
settings likely to be 256-512 meg)
• Project the growth capacity (future additional staff) of the server hosting the Thin Client sessions
Workstation PC’s
• Discuss different form factors (laptop, tablet, and desktop) based on client-specific physical
layout of the workspace
• Review the availability of power, and consider the impact of additional power supply points for
laptops or additional shared batteries
• Establish an automated maintenance plan for periodic disk defragmenting
Printing
• Test print from each workstation using ReDoc
• Discuss the conditions under which routine printing will take place. For example, if a Result
Reporting interface is in place, clinical users may not do any routine printing, but medical records
(or other admin staff) may print Plans of Care or other documents routinely.
• Review the physical locations of printers accessible to ReDoc users, and optimize based on
routine usage
Establish an Ongoing Backup and Maintenance Plan: Determine daily, weekly, monthly, quarterly, and
annual maintenance tasks in conjunction with existing plans for other systems.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Draft Daily Checklist
All Servers (including application, SQL, and Thin Client)
• Check the integrity of the previous day’s backup (for more detail on suggested Backup Plans, see
the Minimum Systems Specifications at www.rehabdocumentation.com/hardware )
Draft Weekly Checklist
All Servers (including application, SQL, and Thin Client)
• Check the integrity of all automated maintenance plans
• Check anti-virus and other security related utilities (anti-worm, firewalls, etc) for appropriate
updates
• Check RAID drives (if used) for failures
• Conduct a hard re-boot (complete power down for 30+ seconds).
Draft Monthly Checklist
All Servers (including application, SQL, and Thin Client)
• Check the integrity of Operating System, SQL, and .NET framework service pack updates
(whether configured for automated or manual)
• Spot check Performance Monitor for overall capacity utilization. Trend CPU, memory, disk I/O,
and network traffic over an average work day and review for bottlenecks
Draft Quarterly Checklist
All Servers (including application, SQL, and Thin Client)
• Restore recent backups to ensure backup integrity
• Check Automated Maintenance Routines for appropriate configuration, intervals, and the
possible deletion of ineffective routines or the addition of new routines.
• Check redundant components (ie power supplies, network cards, etc) for fail over preparedness.
• Check Uninterruptable Power Supplies for battery life under no-power circumstances
• Check UPS or line regulator for clean power
• Review physical security measures for protection of PHI
• Check anti-virus and other security related utilities (anti-worm, firewalls, etc) for appropriate
updates.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Local Area, Wide Area, and Wireless Networking
• Monitor overall network utilization, including saturation, packet loss and latency assessments.
Monitor the same for server backbones, and review for redundant connections where
appropriate.
• Monitor and maintain firewall (hardware and/or software) and any intrusion detection or other
security related hardware and applications. Check ports for appropriate security settings.
Thin Client
• Monitor use of different types of users to access memory allocations
� Overall server performance (memory, CPU, network bandwidth, and disk I/O)
� Memory allocation for admin or clerical staff (initial settings likely to be 128-256 meg)
� Memory allocation for heavy use of print preview or wound care by clinical staff (initial
settings likely to be 256-512 meg)
Draft Annual or Semi-annual Checklist (should be scheduled in sync with the Client’s annual
budgeting process)
Managing hardware lifecycles
• Compare existing workstation, server and network hardware to current and projected (for the
next 12 months) minimum and recommended system specifications;
� Assess and advise on the cost/benefit of hardware enhancements for performance or
reliability
� Propose new/replacement hardware acquisition budget where necessary
� Project hardware lifespan for server and network components
All Servers (including application, SQL, and Thin Client)
• Assess the current version of the Operating System for service pack currency and growth
potential. Plan and budget for version updates if appropriate.
Microsoft SQL Server
• Assess the current version of SQL for service pack currency and growth potential. Plan and
budget for version updates if appropriate.
Local Area, Wide Area, and Wireless Networking
• Assess network for bottlenecks (ie low bandwidth NIC‟s, hubs, or switches)
• Check main and redundant switches and/or wireless access points for fail over preparedness.
• Identify single points of failure (ie switches and wireless access points) and install redundant
hardware based on the cost/risk/benefit analysis. A modest investment in an extra switch or
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
wireless access point could keep the server accessible and would leave normal work
uninterrupted in the event of a most failures.
Thin Client
• Project the growth capacity (future additional staff) of the server hosting the Thin Client sessions
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Appendix C: FAQ’s regarding HIPAA Compliance
As a Business Associate to our Clients (who are ‘Covered Entities’ under HIPAA), we often get questions about how
our Clients can best maintain compliance. The Frequently Asked Questions that follow are offered for information
purposes only – as a Covered Entity, each of our Clients should have and maintain their own Privacy and Security
procedures in place to guide daily operations and facilitate compliance.
Question: What is TRDC’s role in protecting the Privacy and Security of Protected Health Information (PHI)
within my production system?
Answer: As a Business Associate, TRDC is only responsible for copies of PHI that are physically in TRDC’s possession
in the course of implementation, training, and support services. TRDC will provide proper security and storage
while providing such services, and will appropriately destroy or de-personalize PHI when such services are
complete. The Client remains solely responsible for all Administrative, Physical, Technical and other Safeguards
for PHI within their production environment, as well as any other non-production environments (e.g., training,
test, etc.) that may hold copies of your production database or other PHI. Refer to your internal privacy and
security manual for details.
Question: Exactly what data elements are considered PHI?
Answer: In broad terms, any information that can be used, alone or in combination with other reasonably
available information, by an anticipated recipient to identify an individual who is a subject of the information. In
accordance with 45 CFR 164.514 the elements of PHI include: names; all elements of address except State; all
elements of dates except year for dates directly related to an individual (i.e., birth date, admission and discharge
dates, dated of death, and all elements of dates indicating age; phone numbers; fax numbers; email addresses;
social security number; medical record number; health plan beneficiary numbers; account numbers or visit IDs;
certification or license numbers; vehicle identifiers and license plate numbers; device identifiers and serial
numbers; web URLs; IP addresses; biometric identifiers including finger and voice prints; full face photographs and
any comparable images; and any other unique identifying number, characteristic or code, including any individually
identifiable info entered into free text fields).
Examples of places where PHI is routinely found include patient reports, some management reports, electronic
interface events, and production databases (including copies and backups). If these data elements are removed or
encrypted from reports or data files, the reports or data files will be considered to be ‘de-personalized’. Note that
the data elements apply to the patient or their relatives, employers or household members.
Question: How should I provide information that includes PHI to the ReDoc staff for support purposes?
Answer: As a general rule, provide PHI on a ‘minimum necessary’ basis. De-personalize when such information
isn’t necessary for troubleshooting. Ensure that you use secure/encrypted email services before sending any PHI
via email, or Secure FTP when transferring files. If your organization does not have encrypted email services,
contact the ReDoc Help Desk for instructions on how to use ReDoc’s encrypted email.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Question: Access Control - Is there a recommended way to manage user authentication globally?
Answer: TRDC encourages Clients to use grant minimum necessary privileges based on role, and to use
Windows/Active Directory as the authentication option within the ReDoc application. When the ReDoc
authentication option is used instead, the ReDoc application requires both a userID and a password, and it is
strongly recommended that the Client’s System Administrator configure the setting within ReDoc Suite to enforce
strong passwords and require a password change at least every 90 days. TRDC also encourages Clients to
configure SQL Server Authentication, Domain Password Policy enforcement, and TLS/SSL.
Question: How should we configure Auto Log-off?
Answer: TRDC recommends enforcing auto-lock for all PCs and servers via Domain Policies. Alternatively, the
ReDoc application can be configured to auto log-off a user at an interval defined by the Client’s System
Administrator. The recommended setting is to log off after 10 minutes of inactivity.
Question: Should we use encryption for our production system?
Answer: Yes. Under ‘Technical Safeguards’ (45 CFR 164.312), encryption is ‘addressable’ by the Covered Entity
(see definition under 45 CFR 164.306(d)(3)). At a minimum, all wireless networks should be protected using
WPA2 or a similar protocol. Data in motion may be made more secure with the use of TLS/SSL configurations
within SQL Server for all client/server communications, which provides server validation to clients and entities
requesting session encryption and secures authentication sessions. This helps protect against server identity
spoofing that could affect ePHI confidentiality. Through mutual authentication and session encryption, these
safeguards can help validate the authenticity and integrity of transmitted ePHI. To ensure the confidentiality of
both local authentication and ePHI in transit, SQL Server should be configured to refuse connections for clients
that do not support session encryption. To accomplish this, ensure the Database engine is configured to “Force
Encryption” in the SQL Server Network Configuration. Clients are encouraged to use certificates generated by a
mutually trusted certificate authority rather than server-generated certificates, especially when communicating
over unprotected networks.
For data at rest, consider the use of Transparent Data Encryption within SQL Server 2008. Alternatives include
encryption at the disk, virtual machine, or volume level, but performance degradation could occur.
Make sure that any thin client (e.g., Citrix or Terminal Services) use has also been subject to a thorough security
review and audit.
Question: How should I destroy electronic copies of PHI?
Answer: Each server and PC used for storing PHI would require a secure delete utility (overwriting empty disk
sectors on hard drives) installed. Single use media (DVDs and CDs) must be physically destroyed. Hard drives from
servers or PCs that have failed will be physically destroyed by hammer or shredding. Flash drives that have stored
PHI must, at a minimum, be physically destroyed by breaking the USB connection from the drive itself.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Question: What should I consider when establishing a Contingency Plan or Emergency Access Procedures?
Answer: Contingency Plans and Emergency Access Procedures (in the event of the catastrophic loss of either the
data center or the building in which it is housed) for PHI used in connection with ReDoc applications should be a
subset of the Covered Entity’s global Contingency Planning. TRDC maintains contingency plans for sustained Help
Desk and Development activities. However, because TRDC does not store PHI on behalf of its Clients, it is unable
to restore lost Client PHI. As specified in our Sales Agreement, the Client/Covered Entity is responsible for all
backups and restorations of backups, including those necessary under Contingency or Emergency Access
circumstances. Considerations:
• Consider the use of paper documentation as one scenario under catastrophic conditions (e.g., no
access to suitable hardware/infrastructure).
• If plans call for full electronic production capability, identify ahead of time the hardware, network and
infrastructure (i.e., power, environmental controls, etc.) upon which an emergency recovery copy of
ReDoc may be loaded. Evaluate the hardware/infrastructure used to support pre-production
environments for potential suitability.
• Include emergency integration planning as a central issue.
• Consider pre-staging emergency accounts using consistent domain and local server principle naming
conventions to facilitate administration, activity logging, and discovery.
• Configure granular auditing on emergency accounts to capture ePHI activity logs.
• Formally review the purpose of every use of emergency accounts. The procedures should be used
only in the case of a validated emergency. Frequent use of these procedures may indicate broader
issues with the access management process.
• Define procedures for de-commissioning the emergency access instance and processes and smoothly
returning to normal operations after recovery.
• Ensure that Emergency Access Procedures are part of HIPAA training programs for all staff and are
appropriately documented.
Question: What are the source documents that define the roles and responsibilities of Covered Entities and
Business Associates?
Answer: The Federal Register is where HIPAA regulations are published during a Notice of Proposed Rulemaking.
Once finalized, they’re stored in the Code of Federal Regulations (CFR). While there are many sections that
comprise HIPAA, much of the regulation that applies to daily activities is covered under Administrative, Physical,
and Technical Safeguards:
Administrative Safeguards (45 CFR 164.308) which includes security/risk management processes, assigned
security responsibility, workforce security, authorization, and clearance procedures, information access
management, security awareness and training, password management, security incident procedures,
contingency plans, self-evaluation, and business associate agreements.
This document was last updated March 9th
, 2012 and may be further updated from time to time.
A current copy of the Hardware and Systems Minimum Specifications may be found at http://www.rehabdocumentation.com/hardware
Physical Safeguards (45 CFR 164.310) which includes facility access controls, maintenance records, workstation
use and security, device and media controls, and data backup and storage.
Technical Safeguards (45 CFR 164.312) which includes access controls, emergency access procedures,
automatic logoffs, encryption and decryption, audit controls, data integrity, person or entity authentication,
and transmission security.
Other source documents include, but are not limited to:
The HIPAA Privacy Rule
The HITECH Act
45 CFR 160: General Administrative Requirements
45 CFR 164: Security and Privacy
74 Federal Register 19006: Guidance specifying the technologies and methodologies that render PHI
Unusable, Unreadable, or Indecipherable. This is the FR that further references the NIST sources below.
National Institute of Standards and Technology (NIST) Publications
NIST Special Pub 800-66 Intro for Implementing HIPAA Security Rule
NIST Special Pub 800-111 Guide to Storage Encryption Technologies for End User Devices (data at rest)
NIST Special Pub 800-52 Guidelines for the Selection and Use of Transport Layer Security (data in motion)
NIST Special Pub 800-88 Guidelines for Media Sanitization (electronic data destruction)
HIMSS Privacy and Security best practices toolkit