HIPAA/Hi-Tech Act Server, Data and Access Security Policy

1.0 Purpose

The purpose of this policy is to establish standards for the base configuration of internal server equipment, protected health information and user access to servers and data that are owned and/or operated by FidelityEHR on behalf of their commercializable software subscription product, FidelityEHR Behavioral and Integrated Health Record software. Effective implementation of this policy will minimize unauthorized access to FidelityEHR proprietary and/or confidential information and technology.

2.0 Policy

2.1 Ownership and Responsibilities

All internal servers used by the FidelityEHR system must be owned by an operational group that is responsible for system administration. Approved server configuration guides must be established and maintained by each operational group, based on business needs and approved by the FidelityEHR Administration Group. Operational groups should monitor configuration compliance and implement an exception policy tailored to their environment. Each operational group must establish a process for changing the configuration guides, which includes review and approval by the FidelityEHR Administration Group.
Servers must be registered within the corporate enterprise management system. At a minimum, the following information is required to positively identify the point of contact:
Server contact(s) and location, and a backup contact.
Hardware and Operating System/Version.
Main functions and applications, if applicable.
Information in the FidelityEHR Administration Group must be kept up-to-date.
Configuration changes for production servers must follow the appropriate change management procedures.

2.2 General Configuration Guidelines

Operating System configuration should be in accordance with these guidelines.
Services and applications that will not be used must be disabled where practical.
Access to services should be logged and/or protected through access-control methods such as TCP Wrappers, if possible.
The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements.
Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication will do.
Always use standard security principles of least required access to perform a function.
Do not use root when a non-privileged account will do.
If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).
Servers should be physically located in an access-controlled environment.
Servers are specifically prohibited from operating from uncontrolled cubicle areas.

2.3 Password Controls

System enforced: specified minimum length password.
System enforced: user passwords automatically changed or revoked after a user defined period has passed.
System enforced: users required to change their passwords following the initial set up or resetting of the password.
History of previously used passwords is maintained by the system to prevent reuse.
Users are provided the capability to change their own passwords at their discretion.
User id’s are disabled after a specified number of consecutive invalid login attempts.
System automatically logs users off after a specified period of inactivity.
Passwords entered in a non-display field.
Passwords encrypted when routed over a network.
Passwords are encrypted in storage.

2.4 Security Administration

System logs unauthorized access attempts by date, time, user id, device and location.
System maintains an audit trail of all security maintenance performed by date, time, user id, device and location and information is easily accessible.
System provides security reports of users and access levels.
System provides a field(s) for personal information to be used for verification of users’ identities for password resets and other maintenance (i.e. SSN, Mother’s Maiden Name, DOB, etc). Fields used would not be a requirement.
System provides varying levels of access within the security application (i.e. Access to only password reset functions or Access to password reset function + Access to add & update users).
System provides varying levels of access within the application.
System uses groups and unique user ids to define levels of access.
System provides the capability to place security controls on each system module and on confidential and critical levels within each module.
System provides capability to restrict access to particular records within the system, based on user id.
System provides encryption of sensitive information transmitted over the network.
Security features comply with Federal (HIPAA) health information standards for data integrity, confidentiality, auditing, and availability.

2.5 Activity Logging

System logs unauthorized access attempts by date, time, user id, device and location.
System maintains an audit trail of all security maintenance performed by date, time, user id, device and location and information is easily accessible.
System logs all accesses (including inquiry, which is required by HIPAA) to client information.
System has auditing capabilities for both online or batch reporting. Can also be exported into Word, Excel, or other leading industry tools.
Logs are archived and can be recalled as needed.

2.6 Monitoring

All security-related events on critical or sensitive systems must be logged and audit trails saved as follows:
All security related logs will be kept online for a minimum of 1 week.
Daily incremental tape backups will be retained for at least 1 month.
Weekly full tape backups of logs will be retained for at least 1 month.
Monthly full backups will be retained for a minimum of 2 years.
Security-related events will be reported to the FidelityEHR Administration Group, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to:
Port-scan attacks.
Evidence of unauthorized access to privileged accounts.
Anomalous occurrences that are not related to specific applications on the host.

3.0 Compliance

Audits will be performed on a regular basis by authorized representatives.
Audits will be managed by the internal audit group or the FidelityEHR Administration Group. The FidelityEHR Administration Group will filter findings not related to a specific operational group and then present the findings to the appropriate support staff for remediation or justification.
Every effort will be made to prevent audits from causing operational failures or disruptions.

4.0 Enforcement

Any employee or contractor found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
Back