Relevant Policies and Procedures

CLOSE MENU

1. Introduction

Relevant Healthcare, Inc. (“Relevant”) is committed to ensuring the confidentiality, privacy, integrity, and availability of all electronic protected health information (ePHI) it receives, maintains, processes and/or transmits on behalf of its Customers. As providers of compliant, hosted infrastructure used by health care providers, Relevant strives to maintain compliance, proactively address information security, mitigate risk for its Customers, and assure known breaches are completely and effectively communicated in a timely manner. The following documents address core policies used by Relevant to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for Relevant Customers.

1.1 Relevant Organizational Concepts

Relevant’s physical infrastructure environment is hosted in the Google Cloud Platform. Network components and supporting network infrastructure are contained within the Google infrastructure and are managed by Google. Physical access to this infrastructure is maintained by Google and is not available to Relevant. The Relevant environment consists of Google Cloud’s firewall; nginx web servers; Ruby application servers; PostgreSQL database servers; and Windows Server virtual machines.

Within the Relevant Platform on Google Cloud, Relevant inherits Google’s encryption-in-transit policy and all hard drives are encrypted so data at rest is also encrypted; this applies to all servers.

Relevant’s Analytics platform is a single-tenant application and Analytics Customers are given dedicated VMs for both playground and production instances within a dedicated class D network subnet.

The segmentation strategies employed by Relevant for Analytics Customers effectively create RFC 1918, or dedicated, private segmented and separated networks and IP spaces, for each Analytics Customer.

With the exception of TLS encrypted web traffic, Google Cloud’s firewall is configured to block all traffic from the public internet to Analytics instances, and developers and customers are only allowed to connect to internal services via a road-warrior VPN connection.

All systems are tested end-to-end for usability, security, and impact prior to deployment to production.

1.2 Version Control

Relevant maintains a history of these policies, including major and minor revision versions, using the git version control system.

2. HIPAA Mappings to Relevant Controls

Below is a list of HIPAA Safeguards and Requirements and the Relevant controls in place to meet those.

Administrative Controls HIPAA Rule Relevant Control
Security Management Process - 164.308(a)(1)(i) Risk Management Policy
Assigned Security Responsibility - 164.308(a)(2) Roles Policy
Workforce Security - 164.308(a)(3)(i) Employee Policies
Information Access Management - 164.308(a)(4)(i) System Access Policy
Security Awareness and Training - 164.308(a)(5)(i) Employee Policy
Security Incident Procedures - 164.308(a)(6)(i) IDS Policy
Contingency Plan - 164.308(a)(7)(i) Disaster Recovery Policy
Evaluation - 164.308(a)(8) Auditing Policy
Physical Safeguards HIPAA Rule Relevant Control
Facility Access Controls - 164.310(a)(1) Facility and Disaster Recovery Policies
Workstation Use - 164.310(b) System Access, Approved Tools, and Employee Policies
Workstation Security - 164.310(‘c’) System Access, Approved Tools, and Employee Policies
Device and Media Controls - 164.310(d)(1) Disposable Media and Data Management Policies
Technical Safeguards HIPAA Rule Relevant Control
Access Control - 164.312(a)(1) System Access Policy
Audit Controls - 164.312(b) Auditing Policy
Integrity - 164.312(‘c’)(1) System Access, Auditing, and IDS Policies
Person or Entity Authentication - 164.312(d) System Access Policy
Transmission Security - 164.312(e)(1) System Access and Data Management Policy
Organizational Requirements HIPAA Rule Relevant Control
Business Associate Contracts or Other Arrangements - 164.314(a)(1)(i) Business Associate Agreements and 3rd Parties Policies
Policies and Procedures and Documentation Requirements HIPAA Rule Relevant Control
Policies and Procedures - 164.316(a) Policy Management Policy
Documentation - 164.316(b)(1)(i) Policy Management Policy
HITECH Act - Security Provisions HIPAA Rule Relevant Control
Notification in the Case of Breach - 13402(a) and (b) Breach Policy
Timelines of Notification - 13402(d)(1) Breach Policy
Content of Notification - 13402(f)(1) Breach Policy

3. Policy Management Policy

Relevant implements policies and procedures to maintain compliance and integrity of data. The Security Officer and Privacy Officer are responsible for maintaining policies and procedures and assuring all Relevant workforce members, business associates, customers, and partners are adherent to all applicable policies. Previous versions of policies are retained to assure ease of finding policies at specific historic dates in time.

3.1 Applicable Standards

3.1.1 Applicable Standards from the HITRUST Common Security Framework

3.1.2 Applicable Standards from the HIPAA Security Rule

3.2 Maintenance of Policies

  1. All policies are stored and updated to maintain Relevant compliance with HIPAA, HITRUST, NIST, and other relevant standards. Updates and version control are done similarly to source code control.
  2. Policy update requests can be made by any workforce member at any time. Furthermore, all policies are reviewed annually by both the Security and Privacy Officer to assure they are accurate and up-to-date.
  3. Relevant employees may request changes to policies using the following process:
    1. The Relevant employee initiates a policy change request by creating a GitHub pull request from a separate branch containing the desired changes.
    2. The Security Officer or the Privacy Officer is assigned to review the policy change request.
    3. Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
    4. If the review is approved, the Security Officer or Privacy Officer then approves the PR.
    5. If the policy change requires technical modifications to production systems, those changes are carried out by authorized personnel using Relevant’s change management process (§9.4).
  4. All policies are made accessible to all Relevant workforce members. The current master policies are published at https://policies.relevant.healthcare.
  5. All policies, and associated documentation, are retained for 6 years from the date of its creation or the date when it last was in effect using Github version history.
  6. The policies and information security policies are reviewed and audited annually, or after significant changes occur to Relevant’s organizational environment. Issues that come up as part of this process are reviewed by Relevant management to assure all risks and potential gaps are mitigated and/or fully addressed. The process for reviewing polices is outlined below:
    1. The Security Officer initiates the policy review by creating an Issue in the Relevant Compliance Management System.
    2. The Security Officer or the Privacy Officer is assigned to review the current Relevant policies (https://policies.relevant.healthcare/).
    3. If changes are made, the above process is used. All changes are documented in the Issue.
    4. Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
    5. If the review is approved, the Security Officer or Privacy Officer then marks the Issue as Done, adding any pertinent notes required.

Additional documentation related to maintenance of policies is outlined in §5.3.1.

4. Risk Management Policy

This policy establishes the scope, objectives, and procedures of Relevant’s information security risk management process. The risk management process is intended to support and protect the organization and its ability to fulfill its mission.

4.1 Applicable Standards

4.1.1 Applicable Standards from the HITRUST Common Security Framework

4.1.2 Applicable Standards from the HIPAA Security Rule

4.2 Risk Management Policies

  1. It is the policy of Relevant to conduct thorough and timely risk assessments of the potential threats and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) (and other confidential and proprietary electronic information) it stores, transmits, and/or processes for its Customers and to develop strategies to efficiently and effectively mitigate the risks identified in the assessment process as an integral part of the Relevant’s information security program.
  2. Risk analysis and risk management are recognized as important components of Relevant’s corporate compliance program and information security program in accordance with the Risk Analysis and Risk Management implementation specifications within the Security Management standard and the evaluation standards set forth in the HIPAA Security Rule, 45 CFR 164.308(a)(1)(ii)(A), 164.308(a)(1)(ii)(B), 164.308(a)(1)(i), and 164.308(a)(8).
    1. Risk assessments are done throughout product life cycles:
    2. Before the integration of new system technologies and before changes are made to Relevant physical safeguards; and
      • These changes do not include routine updates to existing systems, deployments of new systems created based on previously configured systems, deployments of new Customers, or new code developed for operations and management of the Relevant Platform.
    3. While making changes to Relevant physical equipment and facilities that introduce new, untested configurations.
    4. Relevant performs periodic technical and non-technical assessments of the security rule requirements as well as in response to environmental or operational changes affecting the security of ePHI.
  3. Relevant implements security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to:
    1. Ensure the confidentiality, integrity, and availability of all ePHI Relevant receives, maintains, processes, and/or transmits for its Customers;
    2. Protect against any reasonably anticipated threats or hazards to the security or integrity of Customer ePHI;
    3. Protect against any reasonably anticipated uses or disclosures of Customer ePHI that are not permitted or required; and
    4. Ensure compliance by all workforce members.
  4. Any risk remaining (residual) after other risk controls have been applied, requires sign off by the senior management and Relevant’s Security Officer.
  5. All Relevant workforce members are expected to fully cooperate with all persons charged with doing risk management work, including contractors and audit personnel. Any workforce member that violates this policy will be subject to disciplinary action based on the severity of the violation, as outlined in the Relevant Roles Policy.
  6. The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of Relevant’s Security Officer (or other designated employee), and the identified Risk Management Team.
  7. All risk management efforts, including decisions made on what controls to put in place as well as those to not put into place, are documented and the documentation is maintained for six years.
  8. The details of the Risk Management Process, including risk assessment, discovery, and mitigation, are outlined in detail below. The process is tracked, measured, and monitored using the following procedures:
    1. The Security Officer or the Privacy Officer initiates the Risk Management Procedures by creating an Issue in the Relevant Compliance Management System.
    2. The Security Officer or the Privacy Officer is assigned to carry out the Risk Management Procedures.
    3. All findings are documented in an approved spreadsheet that is linked to the Issue.
    4. Once the Risk Management Procedures are complete, along with corresponding documentation, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
    5. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.

4.3 Risk Management Procedures

4.3.1 Risk Assessment

The intent of completing a risk assessment is to determine potential threats and vulnerabilities and the likelihood and impact should they occur. The output of this process helps to identify appropriate controls for reducing or eliminating risk.

4.3.2 Risk Mitigation

Risk mitigation involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the Risk Assessment process to ensure the confidentiality, integrity and availability of Relevant Platform ePHI. Determination of appropriate controls to reduce risk is dependent upon the risk tolerance of the organization consistent with its goals and mission.

4.3.3 Risk Management Schedule

The two principal components of the risk management process - risk assessment and risk mitigation - will be carried out according to the following schedule to ensure the continued adequacy and continuous improvement of Relevant’s information security program:

4.4 Process Documentation

Maintain documentation of all risk assessment, risk management, and risk mitigation efforts for a minimum of six years.

5. Roles Policy

Relevant has a Security Officer [164.308(a)(2)] and Privacy Officer [164.308(a)(2)] appointed to assist in maintaining and enforcing safeguards towards compliance. The responsibilities associated with these roles are outlined below.

5.1 Applicable Standards

5.1.1 Applicable Standards from the HITRUST Common Security Framework

5.1.2 Applicable Standards from the HIPAA Security Rule

5.2 Privacy Officer

The Privacy Officer is responsible for assisting with compliance and security training for workforce members, assuring organization remains in compliance with evolving compliance rules, and helping the Security Officer in his responsibilities.

  1. Provides annual training to all workforce members of established policies and procedures as necessary and appropriate to carry out their job functions, and documents the training provided.
  2. Assists in the administration and oversight of business associate agreements.
  3. Manage relationships with customers and partners as those relationships affect security and compliance of ePHI.
  4. Assist Security Officer as needed.

The current Relevant Privacy Officer is Jacob Hodes (jacob@relevant.healthcare).

5.2.1 Workforce Training Responsibilities

  1. The Privacy Officer facilitates the training of all workforce members as follows:
    1. New workforce members within their first month of employment;
    2. Existing workforce members annually;
    3. Existing workforce members whose functions are affected by a material change in the policies and procedures, within a month after the material change becomes effective;
    4. Existing workforce members as needed due to changes in security and risk posture of Relevant.
  2. The Security Officer or designee maintains documentation of the training session materials and attendees for a minimum of six years.
  3. The training session focuses on, but is not limited to, the following subjects defined in Relevant’s security policies and procedures:
    1. HIPAA Privacy, Security, and Breach notification rules;
    2. HITRUST Common Security Framework;
    3. NIST Security Rules;
    4. Risk Management procedures and documentation;
    5. Auditing. Relevant may monitor access and activities of all users;
    6. Workstations may only be used to perform assigned job responsibilities;
    7. Users may not download software onto Relevant’s workstations and/or systems without prior approval from the Security Officer;
    8. Users are required to report malicious software to the Security Officer immediately;
    9. Users are required to report unauthorized attempts, uses of, and theft of Relevant’s systems and/or workstations;
    10. Users are required to report unauthorized access to facilities
    11. Users are required to report noted log-in discrepancies (i.e. application states users last log-in was on a date user was on vacation);
    12. Users may not alter ePHI maintained in a database, unless authorized to do so by a Relevant Customer;
    13. Users are required to understand their role in Relevant’s contingency plan;
    14. Users may not share their user names nor passwords with anyone;
    15. Requirements for users to create and change passwords;
    16. Users must set all applications that contain or transmit ePHI to automatically log off after 15 minutes of inactivity;
    17. Supervisors are required to report terminations of workforce members and other outside users;
    18. Supervisors are required to report a change in a users title, role, department, and/or location;
    19. Procedures to backup ePHI;
    20. Procedures to move and record movement of hardware and electronic media containing ePHI;
    21. Procedures to dispose of discs, CDs, hard drives, and other media containing ePHI;
    22. Procedures to re-use electronic media containing ePHI;
    23. SSH key and sensitive document encryption procedures.

5.3 Security Officer

The Security Officer is responsible for facilitating the training and supervision of all workforce members [164.308(a)(3)(ii)(A) and 164.308(a)(5)(ii)(A)], investigation and sanctioning of any workforce member that is in violation of Relevant security policies and non-compliance with the security regulations [164.308(a)(1)(ii)(c)], and writing, implementing, and maintaining all polices, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)].

The current Relevant Security Officer is Brandon Hamilton (brandon@relevant.healthcare).

5.3.1 Organizational Responsibilities

The Security Officer, in collaboration with the Privacy Officer, is responsible for facilitating the development, testing, implementation, training, and oversight of all activities pertaining to Relevant’s efforts to be compliant with the HIPAA Security Regulations, HITRUST CSF, and any other security and compliance frameworks. The intent of the Security Officer Responsibilities is to maintain the confidentiality, integrity, and availability of ePHI. The Security Officer is appointed by and reports to the Board of Directors and the CEO.

These organizational responsibilities include, but are not limited to the following:

  1. Oversees and enforces all activities necessary to maintain compliance and verifies the activities are in alignment with the requirements.
  2. Helps to establish and maintain written policies and procedures to comply with the Security rule and maintains them for six years from the date of creation or date it was last in effect, whichever is later.
  3. Reviews and updates policies and procedures as necessary and appropriate to maintain compliance and maintains changes made for six years from the date of creation or date it was last in effect, whichever is later.
  4. Facilitates audits to validate compliance efforts throughout the organization.
  5. Documents all activities and assessments completed to maintain compliance and maintains documentation for six years from the date of creation or date it was last in effect, whichever is later.
  6. Provides copies of the policies and procedures to management, customers, and partners, and has them available to review by all other workforce members to which they apply.
  7. Annually, and as necessary, reviews and updates documentation to respond to environmental or operational changes affecting the security and risk posture of ePHI stored, transmitted, or processed within Relevant infrastructure.
  8. Develops and provides periodic security updates and reminder communications for all workforce members.
  9. Implements procedures for the authorization and/or supervision of workforce members who work with ePHI or in locations where it may be accessed.
  10. Maintains a program promoting workforce members to report non-compliance with policies and procedures.
    • Promptly, properly, and consistently investigates and addresses reported violations and takes steps to prevent recurrence.
    • Applies consistent and appropriate sanctions against workforce members who fail to comply with the security policies and procedures of Relevant.
    • Mitigates, to the extent practicable, any harmful effect known to Relevant of a use or disclosure of ePHI in violation of Relevant’s policies and procedures, even if effect is the result of actions of Relevant business associates, customers, and/or partners.
  11. Reports security efforts and incidents to administration immediately upon discovery. Responsibilities in the case of a known ePHI breach are documented in the Relevant Breach Policy.
  12. The Security Officer facilitates the communication of security updates and reminders to all workforce members to which it pertains. Examples of security updates and reminders include, but are not limited to:
    • Latest malicious software or virus alerts;
    • Relevant’s requirement to report unauthorized attempts to access ePHI;
    • Changes in creating or changing passwords;
    • Additional security-focused training is provided to all workforce members by the Security Officer. This training includes, but is not limited to:
    • Data backup plans;
    • System auditing procedures;
    • Redundancy procedures;
    • Contingency plans;
    • Virus protection;
    • Patch management;
    • Media Disposal and/or Re-use;
    • Documentation requirements.

5.3.2 Supervision of Workforce Responsibilities

Although the Security Officer is responsible for implementing and overseeing all activities related to maintaining compliance, it is the responsibility of all workforce members (i.e. team leaders, supervisors, managers, directors, co-workers, etc.) to supervise all workforce members and any other user of Relevant’s systems, applications, servers, workstations, etc. that contain ePHI.

  1. Monitor workstations and applications for unauthorized use, tampering, and theft and report non-compliance according to the Security Incident Response policy.
  2. Assist the Security and Privacy Officers to ensure appropriate role-based access is provided to all users.
  3. Take all reasonable steps to hire, retain, and promote workforce members and provide access to users who comply with the Security regulation and Relevant’s security policies and procedures.

5.3.3 Sanctions of Workforce Responsibilities

All workforce members report non-compliance of Relevant’s policies and procedures to the Security Officer or other individual as assigned by the Security Officer. Individuals that report violations in good faith may not be subjected to intimidation, threats, coercion, discrimination against, or any other retaliatory action as a consequence.

  1. The Security Officer promptly facilitates a thorough investigation of all reported violations of Relevant’s security policies and procedures. The Security Officer may request the assistance from others.
    • Complete an audit trail/log to identify and verify the violation and sequence of events.
    • Interview any individual that may be aware of or involved in the incident.
    • All individuals are required to cooperate with the investigation process and provide factual information to those conducting the investigation.
    • Provide individuals suspected of non-compliance of the Security rule and/or Relevant’s policies and procedures the opportunity to explain their actions.
    • The investigator thoroughly documents the investigation as the investigation occurs. This documentation must include a list of all employees involved in the violation.
  2. Violation of any security policy or procedure by workforce members may result in corrective disciplinary action, up to and including termination of employment. Violation of this policy and procedures by others, including business associates, customers, and partners may result in termination of the relationship and/or associated privileges. Violation may also result in civil and criminal penalties as determined by federal and state laws and regulations.
    • A violation resulting in a breach of confidentiality (i.e. release of PHI to an unauthorized individual), change of the integrity of any ePHI, or inability to access any ePHI by other users, requires immediate termination of the workforce member from Relevant.
  3. The Security Officer facilitates taking appropriate steps to prevent recurrence of the violation (when possible and feasible).
  4. In the case of an insider threat, the Security Officer and Privacy Officer are to set up a team to investigate and mitigate the risk of insider malicious activity. Relevant workforce members are encouraged to come forward with information about insider threats, and can do so anonymously.
  5. The Security Officer maintains all documentation of the investigation, sanctions provided, and actions taken to prevent reoccurrence for a minimum of six years after the conclusion of the investigation.

6. Data Management Policy

Relevant has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI) stored in the Analytics platform. This policy, and associated procedures for testing and restoring from backup data, will assure that complete, accurate, retrievable, and tested backups are available for all systems used by Relevant.

Data backup is an important part of the day-to-day operations of Relevant. To protect the confidentiality, integrity, and availability of ePHI, both for Relevant and Relevant Customers, complete backups are done daily to assure that data remains available when it needed and in case of a disaster.

Violation of this policy and its procedures by workforce members may result in corrective disciplinary action, up to and including termination of employment.

6.1 Applicable Standards

6.1.1 Applicable Standards from the HITRUST Common Security Framework

6.1.2 Applicable Standards from the HIPAA Security Rule

6.1.3 Applicable Standards from the NYSDOH SSP Framework

6.2 Backup Policy and Procedures

  1. Perform daily snapshot backups of all systems that process, store, or transmit ePHI for Relevant Customers.
  2. The Relevant Engineering Team is designated to be in charge of backups.
  3. The Relevant Engineering Team owns the automation, management, and monitoring of backup media and processes.
  4. Document backups
    • Name of the system
    • Date & time of backup
    • Where backup stored (or to whom it was provided)
  5. Securely encrypt stored backups in a manner that protects them from loss or environmental damage.
  6. Test backups annually and document that files have been completely and accurately restored from the backup media.

6.3 Use of Live Data

  1. Live data is used in staging environments; data in staging environments is subject to the same security controls as those of the production environment.
  2. Data used in demo environments is synthetic or de-identified and not subject to the security controls of production or staging environments.

7. System Access Policy

Access to Relevant systems and application is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the organization’s information systems. These safeguards have been established to address the HIPAA Security regulations including the following:

7.1 Applicable Standards

7.1.1 Applicable Standards from the HITRUST Common Security Framework

7.1.2 Applicable Standards from the HIPAA Security Rule

7.1.3 Applicable Standards from NYSDOH SSP Framework

7.2 Access Establishment and Modification

  1. Requests for access to Relevant Platform systems and applications is made formally using the following process:
    1. A Relevant workforce member initiates the access request by creating an Issue in the Relevant Compliance Management System.
      • User identities must be verified prior to granting access to new accounts.
      • Identity verification must be done in person where possible; for remote employees, identities must be verified over the phone.
      • For new accounts, the method used to verify the user’s identity must be recorded on the Issue.
    2. The Security Officer or Privacy Officer will grant access to systems as dictated by the employee’s job title. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
    3. Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
    4. If the review is approved, the Security Officer or Privacy Officer then marks the Issue as Done, adding any pertinent notes required. The Security Officer or Privacy Officer then grants requested access.
      • New accounts will be created with a temporary secure password that meets all requirements from §7.12, which must be changed on the initial login.
      • All password exchanges must occur over an authenticated channel.
      • For production systems, access grants are accomplished by adding the appropriate user account to the corresponding LDAP group.
      • For non-production systems, access grants are accomplished by leveraging the access control mechanisms built into those systems. Account management for non-production systems may be delegated to a Relevant employee at the discretion of the Security Officer or Privacy Officer .
  2. Access is not granted until receipt, review, and approval by the Relevant Security Officer or Privacy Officer ;
  3. The request for access is retained for future reference.
  4. All access to Relevant systems and services is reviewed and updated on a bi-annual basis to ensure proper authorizations are in place commensurate with job functions. The process for conducting reviews is outlined below:
    1. The Security Officer initiates the review of user access by creating an Issue in the Relevant Compliance Management System.
    2. The Security Officer is assigned to review levels of access for each Relevant workforce member.
    3. If user access is found during review that is not in line with the least privilege principle, the process below is used to modify user access and notify the user of access changes. Once those steps are completed, the Issue is then reviewed again.
    4. Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
    5. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
    6. Review of user access is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.
  5. Any Relevant workforce member can request change of access using the process outlined in §7.2 paragraph 1.
  6. Access to production systems is controlled using centralized user management and authentication.
  7. Temporary accounts are not used unless absolutely necessary for business purposes.
    • Accounts are reviewed every 14 days to ensure temporary accounts are not left unnecessarily.
    • Temporary accounts with access to infrastructure are configured to automatically expire using Google Cloud’s expiring access condition features.
  8. In the case of non-personal information, such as generic educational content, identification and authentication may not be required. This is the responsibility of Relevant Customers to define, and not Relevant.
  9. Privileged users must first access systems using standard, unique user accounts before switching to privileged users and performing privileged tasks.
    • For production systems, this is enforced by creating non-privileged user accounts that must invoke sudo to perform privileged tasks.
    • Rights for privileged accounts are granted by the Security Officer or Privacy Officer using the process outlined in §7.2 paragraph 1.
  10. All application to application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems.
  11. Generic accounts are not allowed on Relevant systems.
  12. Access is granted through encrypted, VPN tunnels that utilize two-factor authentication.
    • Two-factor authentication is accomplished using a Time-based One-Time Password (TOTP) as the second factor.
    • VPN connections use 256-bit AES 256 encryption, or equivalent.
    • VPN sessions are automatically disconnected after 30 minutes of inactivity.
  13. In cases of increased risk or known attempted unauthorized access, immediate steps are taken by the Security and Privacy Officer to limit access and reduce risk of unauthorized access.
  14. Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access.
  15. All accounts and assigned security roles are reviewed every 14 days by the Security Officer.

7.3 Workforce Clearance

  1. The level of security assigned to a user to the organization’s information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user’s job classification and/or to a user needing access to carry out treatment, payment, or healthcare operations.
  2. All access requests are treated on a “least-access principle.”
  3. Relevant maintains a minimum necessary approach to access to Customer data. As such, Relevant, including all workforce members, does not readily have access to any ePHI.

7.4 Access Authorization

  1. Role based access categories for each Relevant system and application are pre-approved by the Security Officer, or an authorized delegate of the Security Officer.
  2. Relevant utilizes hardware and software firewalls to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.

7.5 Person or Entity Authentication

  1. Each workforce member has and uses a unique user ID and password that identifies him/her as the user of the information system.
  2. Each Customer and Partner has and uses a unique user ID and password that identifies him/her as the user of the information system.
  3. All Customer support desk interactions must be verified before Relevant support personnel will satisfy any request having information security implications.
    • Relevant’s current support desk software, Zendesk, requires users to authenticate before submitting support tickets.
    • Support issues submitted via Relevant’s dashboard require that users authenticate with their Relevant account before submitting support tickets.
    • Support issues submitted by email must be verified by Relevant personnel using a phone number that has been registered with the corresponding account.

7.6 Unique User Identification

  1. Access to the Relevant Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
  2. Passwords requirements mandate strong password controls (see below).
  3. Passwords are not displayed at any time and are not transmitted or stored in plain text.
  4. Default accounts on all production systems, including root, are disabled.
  5. Shared accounts are not allowed within Relevant systems or networks.
  6. Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with Relevant workstations or production systems.

7.7 Automatic Logoff

  1. Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
  2. Information systems automatically log users off the systems after 15 minutes of inactivity.
  3. The Security Officer pre-approves exceptions to automatic log off requirements.

7.8 Employee Workstation Use

All workstations at Relevant are company owned, and all are laptop Apple products running Mac OSX or Linux.

  1. Workstations may not be used to engage in any activity that is illegal or is in violation of organization’s policies.
  2. Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or “X-rated”. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through organization’s system.
  3. Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization’s best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
  4. Solicitation of non-company business, or any use of organization’s information systems/applications for personal gain is prohibited.
  5. Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.
  6. Workstation hard drives will be encrypted using FileVault 2.0 or equivalent.
  7. All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.
  8. All workstations are to have the following messages added to the lock screen and login screen: By logging in, unlocking, or using this computer, you acknowledge that you have completed Relevant’s HIPAA training, and have reviewed and agree to follow Relevant’s policies and procedures.

7.9 Wireless Access Use

  1. Relevant production systems are not accessible directly over wireless channels.
  2. Wireless access is disabled on all production systems.
  3. When accessing production systems via remote wireless connections, the same system access policies and procedures apply to wireless as all other connections, including wired.
  4. Wireless networks managed within Relevant non-production facilities (offices, etc.) are secured with the following configurations:
    • All data in transit over wireless is encrypted using WPA2 encryption;

7.10 Employee Termination Procedures

  1. The Human Resources Department (or other designated department), users, and their supervisors are required to notify the Security Officer upon completion and/or termination of access needs and facilitating completion of the “Termination Checklist”.
  2. The Human Resources Department, users, and supervisors are required to notify the Security Officer to terminate a user’s access rights if there is evidence or reason to believe the following (these incidents are also reported on an incident report and is filed with the Privacy Officer):
    • The user has been using their access rights inappropriately;
    • A user’s password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password);
    • An unauthorized individual is utilizing a user’s User Login ID and password (a new password may be provided to the user if the user is not identified as providing the unauthorized individual with the User Login ID and password).
  3. The Security Officer will terminate users’ access rights immediately upon notification, and will coordinate with the appropriate Relevant employees to terminate access to any non-production systems managed by those employees.
  4. The Security Officer audits and may terminate access of users that have not logged into organization’s information systems/applications for an extended period of time.

7.11 Paper Records

Relevant does not use paper records for any sensitive information. Use of paper for recording and storing sensitive data is against Relevant policies.

7.12 Password Management

  1. User IDs and passwords are used to control access to Relevant systems and may not be disclosed to anyone for any reason.
  2. Users may not allow anyone, for any reason, to have access to any information system using another user’s unique user ID and password.
  3. On all production systems and applications in the Relevant environment, password configurations are set to require:
    • a minimum length of 8 characters with capital, lowercase, and number
    • OR minimum 20 characters with no restrictions
  4. All system and application passwords must be stored and transmitted securely.
    • Where possible, passwords should be stored in a hashed format using a salted cryptographic hash function (SHA-256 or equivalent).
    • Passwords that must be stored in non-hashed format must be encrypted at rest pursuant to the requirements in §17.8.
    • Transmitted passwords must be encrypted in flight pursuant to the requirements in §17.9.
  5. Each information system automatically requires users to change passwords at a pre-determined interval as determined by the organization, based on the criticality and sensitivity of the ePHI contained within the network, system, application, and/or database.
  6. Passwords are inactivated immediately upon an employee’s termination (refer to the Employee Termination Procedures in §7.10).
  7. All default system, application, and Partner passwords are changed before deployment to production.
  8. Upon initial login, users must change any passwords that were automatically generated for them.
  9. Password change methods must use a confirmation method to correct for user input errors.
  10. All passwords used in configuration scripts are secured and encrypted.
  11. If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security Office.
  12. In cases where a user has forgotten their password, the following procedure is used to reset the password.
    • The user submits a password reset request to password-reset@relevant.healthcare. The request should include the system to which the user has lost access and needs the password reset.
    • An administrator with password reset privileges is notified and connects directly with the user requesting the password reset.
    • The administrator verifies the identity of the user either in-person or through a separate communication channel such as phone or Slack.
    • Once verified, the administrator resets the password.

The password-reset email inbox is used to track and store password reset requests. The Security Officer is the owner of this group and modifies membership as needed.

7.13 Access to ePHI

  1. All production access to systems is through an encrypted VPN. Direct access to production systems is disallowed by Relevant’s VPN configuration.
  2. Employees may download ePHI to their workstations only when to satisfy a particular purpose or carry out a function necessary to their role.
  3. If ePHI is downloaded to this end, it must be deleted from their workstation.

7.14 Analytics Customer Access to Systems

Relevant grants Analytics customer secure system access via VPN connections. This access is only to Customer-specific systems, no other systems in the environment. These connections are setup at customer deployment. These connections are secured and encrypted and the only method for customers to connect directly to Relevant hosted systems.

In the case of data migration, Relevant does, on a case by case basis, support customers in importing data. In these cases Relevant requires that all data is secured and encrypted in transit, such as by using SFTP or SCP for transferring files.

In the case of an investigation, Relevant will assist customers, at Relevant’s discretion, and law enforcement in forensics.

7.15 Emergency Access Procedures

Relevant’s cloud-based infrastructure and redundant access to ePHI is set up to ensure that Engineering Team leads can maintain access to ePHI even in the cases when environmental systems, such as electrical power, have been severely damaged or rendered inoperative due to a natural or manmade disaster.

8. Auditing Policy

The Security Rule requires healthcare organizations to implement reasonable hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

Relevant shall audit access and activity of electronic protected health information (ePHI) applications and systems in order to ensure compliance. Audit activities may be limited by application, system, and/or network auditing capabilities and resources. Relevant shall make reasonable and good-faith efforts to safeguard information privacy and security through a well-thought-out approach to auditing that is consistent with available resources.

It is the policy of Relevant to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, Relevant shall audit access and activity to detect, report, and guard against:

This policy applies to all Relevant systems that store, transmit, or process ePHI.

8.1 Applicable Standards

8.1.1 Applicable Standards from the HITRUST Common Security Framework

8.1.2 Applicable Standards from the HIPAA Security Rule

8.1.3 Applicable Standards from NYSDOH SSP Framework

8.2 Auditing Policies

  1. Responsibility for auditing information system access and activity is assigned to Relevant’s Security Officer. The Security Officer shall:

    • Assign the task of generating reports for audit activities to the workforce member responsible for the application, system, or network;
    • Assign the task of reviewing the audit reports to the workforce member responsible for the application, system, or network, the Privacy Officer, or any other individual determined to be appropriate for the task;
    • Organize and provide oversight to a team structure charged with audit compliance activities (e.g., parameters, frequency, sample sizes, report formats, evaluation, follow-up, etc.).

  2. Auditing policies and procedures are reviewed on an annual basis, per SSP AU-1.

  3. Relevant’s auditable events include the following:

    • Google Cloud: as specified in the PHI Asset Inventory
    • Google Admin: as specified in the PHI Asset Inventory
    • Google Drive: as specified in the PHI Asset Inventory
    • Application
      • Login attempts (successful and unsuccessful)
      • File uploads/downloads
      • Individual page views at webserver level
      • Individual page views at application code level
      • Server side errors
      • Client side errors
      • Response times
      • Outages
      • Query timeouts
      • Data creation, modification, deletion
      • Background jobs (successful and unsuccessful)

  4. Whenever feasible, log records contain the following details, per SSP AU-2 and SSP AU-3:

    • Origin, destination, date, and time of the event;
    • The component of the information system and type of event;
    • An identifier linking the audit record to an individual user or subject;
    • The outcome (e.g., success or failure) of the event;
    • Sufficient information for an audit reviewer to determine whether a prileged function was executed; and
    • The specific command that was executed (for process creation events)

  5. Relevant utilizes OSSEC to scan all systems for malicious and unauthorized software every 2 hours and at reboot of systems.

  6. Relevant uses OSSEC to monitor the integrity of log files by utilizing OSSEC System Integrity Checking capabilities.

  7. Vulnerability scanning is peformed no less frequently than monthly, and the results are inspected by the appropriate personnel.

  8. Software patches and updates are applied to all systems in a timely manner.

  9. The procedure for review of audit logs includes:

    • Description of the audit log review procedure;
    • Frequency of the procedure;
    • Identification of the workforce members responsible for the procedure;
    • Identification of appropriate reporting channels for audit results and required follow-up; and
    • Determination of significant events requiring further review and follow-up.

8.3 Review and Reporting of Audit Findings

  1. Audit information that is routinely gathered is reviewed on a weekly basis by the responsible workforce member(s), per SSP AU-6.
  2. Relevant escalates the review, analysis, and reporting within the information system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information, per SSP AU-6(10).
  3. Whenever indicated through evaluation and reporting, appropriate corrective actions is undertaken.

8.4 Audit Log Security Controls and Backup

  1. Audit logs shall be protected from unauthorized access or modification, per SSP AU-7 and AU-9.
  2. Audit logs are protected in transit and encrypted at rest to control access to the content of the logs.
  3. Audit logs shall be stored on a separate system to minimize the impact on production systems.
  4. In the event of an audit processing failure or audit storage capacity issue, systems will be shut down within 1 hour of the audit processing failure, per SSP AU-5.

8.5 Workforce Training, Education, Awareness and Responsibilities

  1. Relevant workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI. Relevant’s commitment to auditing access and activity of the information applications, systems, and networks is communicated through new employee orientation, ongoing training opportunities and events, and applicable policies. Relevant workforce members are made aware of responsibilities with regard to privacy and security of information as well as applicable sanctions/corrective disciplinary actions should the auditing process detect a workforce member’s failure to comply with organizational policies.

8.6 Retention of Audit Data

  1. Audit logs are retained for a minimum of one year, per SSP AU-11, and longer when practicable.
  2. Reports summarizing audit activities are retained for a period of six years, per the HIPAA Security Rule.

9. Configuration Management Policy

9.1 Applicable Standards

9.1.1 Applicable Standards from the HITRUST Common Security Framework

9.1.2 Applicable Standards from the HIPAA Security Rule

9.1.3 Applicable Standards from the NYSDOH SSP

9.2 Configuration Management Policies

  1. Google Cloud images are used to standardize and automate configuration management.
  2. No systems are deployed into Relevant environments without approval of the Security Officer.
  3. All changes to production systems, network devices, and firewalls are approved by the Security Officer before they are implemented to assure they comply with business and security requirements.
  4. All changes to production systems are tested before they are implemented in production.
  5. Implementation of approved changes are only performed by authorized personnel.
  6. Relevant maintains an up to date list of systems containing ePHI.
  7. All frontend functionality (developer dashboards and portals) is separated from backend (database and app servers) systems by being deployed on separate servers or containers.
  8. All software and systems are tested using unit tests and end to end tests.
  9. All committed code is reviewed using pull requests to assure software code quality and proactively detect potential security issues in development.
  10. Relevant utilizes development and staging (playground) environments that mirror production to assure proper function.
  11. Relevant uses CircleCI to run a comprehensive test suite before releases are shipped to production. All tests must pass before new code is deployed.
  12. All formal change requests require unique ID and authentication.
  13. Clocks are continuously synchronized to an authoritative source across all systems using NTP or a platform-specific equivalent. Modifying time data on systems is restricted.
  14. For all VMs within the information boundary governed by NYS SSP framework, CIS (Center for Internet Security) hardened images are used as a baseline, and all modifications are documented.

9.3 Provisioning Production Systems

  1. Before provisioning any systems, ops team members get explicit permission from the Security Officer.
  2. The Security Officer, or an authorized delegate of the Security Officer, must approve the provisioning request before any new system can be provisioned.
  3. Once provisioning has been approved, the ops team member must configure the new system according to the standard baseline chosen for the system’s role.
  4. Once the system has been provisioned, the ops team member must contact the security team to inspect the new system. A member of the security team will verify that the secure baseline has been applied to the new system, including (but not limited to) verifying the following items:
    • Removal of default users used during provisioning.
    • Network configuration for system.
    • Data volume encryption settings.
    • Intrusion detection and virus scanning software installed.
    • All items listed below in the operating system-specific subsections below.
  5. The new system may be rotated into production once the Security Officer verifies all the provisioning steps listed above have been correctly followed.

9.3.1 Provisioning Linux Systems

  1. Linux systems have their baseline security verified by:
    • Ensuring that the machine is up-to-date with security patches and is configured to apply patches in accordance with our policies.
    • Stopping and disabling any unnecessary OS services.
    • Installing and configuring the OSSEC IDS agent.
    • Configuring 15-minute session inactivity timeouts.
    • Installing and configuring the ClamAV virus scanner.
    • Installing and configuring the NTP daemon, including ensuring that modifying system time cannot be performed by unprivileged users.
    • Configuring audit logging as described in the Auditing Policy section.

9.3.2 Provisioning Windows Systems

  1. Windows systems have their baseline security configuration verified by:
    • Ensuring that the machine is up-to-date with security patches and is configured to apply patches in accordance with our policies.
    • Stopping and disabling any unnecessary OS services.
    • Installing and configuring the Avast virus scanner.
    • Configuring transport encryption according to the requirements described in §17.9.
    • Configuring the system clock, including ensuring that modifying system time cannot be performed by unprivileged users.
    • Configuring audit logging as described in the Auditing Policy section.

9.3.3 Provisioning Management Systems

  1. Provisioning management systems such as VPN appliances follows the same procedure as provisioning a production system.
  2. Critical infrastructure roles applied to new systems must be clearly documented by the ops team member.

9.4 Changing Existing Systems

  1. Subsequent changes to already-provisioned systems must be explicitly approved by the Security Officer.

9.5 Patch Management Procedures

  1. Relevant uses automated tooling to ensure systems are up-to-date with the latest security patches.
  2. On CentOS and Debian Linux systems, the yum-cron and the unattended-upgrades tool are used to apply security patches in phases.
    • Patches for critical kernel security vulnerabilities may be applied to production systems using hot-patching tools at the discretion of the Security Officer. These patches must follow the same phased testing process used for non-kernel security patches; this process may be expedited for severe vulnerabilities.
  3. On Windows systems, the baseline Group Policy setting configures Windows Update to implement the patching policy.

9.6 Software Development Procedures

  1. All development uses feature branches based on the main branch used for the current release. Any changes required for a new feature or defect fix are committed to that feature branch.
    • These changes must be covered under 1) a unit test where possible, or 2) integration tests.
    • Integration tests are required if unit tests cannot reliably exercise all facets of the change.
  2. Developers are strongly encouraged to follow the commit message conventions suggested by GitHub.
    • Commit messages should be wrapped to 72 characters.
    • Commit messages should be written in the present tense. This convention matches up with commit messages generated by commands like git merge and git revert.
  3. Once the feature and corresponding tests are complete, a pull request will be created using the GitHub/GitLab web interface. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.
  4. Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the author(s) will notify other engineers using an appropriate mechanism, typically via an @channel message in Slack.
    • Other engineers will review the changes, using the guidelines above.
    • Engineers should note all potential issues with the code; it is the responsibility of the author(s) to address those issues or explain why they are not applicable.
  5. If the feature or defect interacts with ePHI, or controls access to data potentially containing ePHI, the code changes must be reviewed by a member of Relevant’s Security Committee before the feature is marked as complete.
    • This review must include a security analysis for potential vulnerabilities such as those listed in the OWASP Top 10 or the CWE top 25.
    • This review must also verify that any actions performed by authenticated users will generate appropriate audit log entries.
  6. The review process is complete when the reviewer leaves a comment on the Pull Request saying “Merge Approved” (or, abbreviated, “MA”), at which point the original author(s) may merge their change into the release branch.

9.7 Software Release Procedures

  1. Software releases are treated as changes to existing systems and thus follow the procedure described in §9.4.

9.8 Mobile code

Relevant prohibits the use of the following mobile technologies on its endpoints and servers:

Java Applets, ActiveX plugins, Shockwave movies, Flash animations, and VBScript

10. Facility Access Policy

Relevant works with Subcontractors to assure restriction of physical access to systems used as part of the Relevant Platform. Relevant and its Subcontractors control access to the physical buildings/facilities that house these systems/applications, or in which Relevant workforce members operate, in accordance to the HIPAA Security Rule 164.310 and its implementation specifications. Physical Access to all of Relevant facilities is limited to only those authorized in this policy. In an effort to safeguard ePHi from unauthorized access, tampering, and theft, access is allowed to areas only to those persons authorized to be in them and with escorts for unauthorized persons. All workforce members are responsible for reporting an incident of unauthorized visitor and/or unauthorized access to Relevant’s facility.

Of note, Relevant does not physically house any systems used by its Platform. Physical security of our Platform servers is outlined in §1.2.

Relevant inherits much of its physical security posture in the small physical space it rents from WeWork.

10.1 Applicable Standards

10.1.1 Applicable Standards from the HIPAA Security Rule

10.2 Relevant-controlled Facility Access Policies

  1. WeWork provides individual keycards to authorized employees and uses automatic locks and alarms.
  2. Visitors to Relevant’s WeWork are required to check in with photo id and have an escort.
  3. Relevant provides guidance to employees during training about protecting physical space and visible PHI in a home-office setting.
  4. Relevant’s employees agree to a use policy design to minimize risk.
  5. Workstation Security
    • Workstations may only be accessed and utilized by authorized workforce members to complete assigned job/contract responsibilities. This is covered in employee training.
    • Workstations have encryption centrally enforced, thus minimizing risk in case of physical compromise.
    • Workstations have centrally-enforced session timeouts of 15 minutes, further reducing risk of accessing data in the case of theft/compromise.
    • All workforce members are required to monitor workstations and report unauthorized users and/or unauthorized attempts to access systems/applications as per the System Access Policy.
    • All workstations purchased by Relevant are the property of Relevant and are distributed to users by the company.

11. Incident Response Policy

Relevant implements an information security incident response process to consistently detect, respond, and report incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore information system functionality and business continuity as soon as possible.

The incident response process addresses:

11.1 Applicable Standards

11.1.1 Applicable Standards from the HITRUST Common Security Framework

11.1.2 Applicable Standards from the HIPAA Security Rule

11.2 Incident Management Policies

Relevant’s incident response classifies security-related events into the following categories:

Relevant employees must report any unauthorized or suspicious activity seen on production systems or associated with related communication systems (such as email or Slack). In practice this means keeping an eye out for security events, and letting the Security Officer know about any observed precursors or indications as soon as they are discovered.

11.2.1 Identification Phase

  1. Immediately upon observation Relevant employees report suspected and known Events, Precursors, Indications, and Incidents in one of the following ways:
    1. Direct report to management, the Security Officer, or Privacy Officer.
    2. Phone call.
    3. Secure Chat.
    4. Anonymously through desired channels.
  2. The individual receiving the report notifies the Security Officer (if not already done).
  3. The Security Officer determines if the issue is an Event, Precursor, Indication, or Incident.
    1. If the issue is an indication, or precursor the Security Officer documents the designation in the compliance log. The Security Officer may also request a post-mortem be done to ensure that issues do not escalate or to learn root causes.
    2. If the issue is designated a security incident the Security Officer activates the Security Incident Response Team (SIRT) and notifies senior management.
      1. If a non-technical security incident is discovered the SIRT completes the investigation, implements preventative measures, and resolves the security incident.
      2. Once the investigation is completed, progress to Phase V, Follow-up.
      3. If the issue is a technical security incident, commence to Phase II: Containment.
      4. The Containment, Eradication, and Recovery Phases are highly technical. It is important to have them completed by a highly qualified technical security resource with oversight by the SIRT team.
      5. Each individual on the SIRT and the technical security resource document all measures taken during each phase, including the start and end times of all efforts.
      6. The lead member of the SIRT team facilitates the writing of a summary of all events, efforts, and conclusions of each Phase of this policy and procedures.
  4. The Security Officer, Privacy Officer, or Relevant representative appointed notifies any affected Customers and Partners. If no Customers and Partners are affected, notification is at the discretion of the Security and Privacy Officer.
  5. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to Relevant and potentially external.

11.2.2 Containment Phase (Technical)

In this Phase, Relevant’s engineers attempt to contain the security incident. It is extremely important to take detailed notes during the security incident response process. This provides that the evidence gathered during the security incident can be used successfully during prosecution, if appropriate.

  1. The SIRT reviews any information that has been collected by the Security Officer or any other individual investigating the security incident.
  2. The SIRT secures the network perimeter.
  3. Engineers perform the following:
    1. Securely connect to the affected system over a trusted connection.
    2. Retrieve any volatile data from the affected system.
    3. Determine the relative integrity and the appropriateness of backing the system up.
    4. If appropriate, back up the system.
    5. Change the password(s) to the affected system(s).
    6. Determine whether it is safe to continue operations with the affect system(s).
      1. If the incident is a ransomware-related incident, it is considered safe to shutdown the machine, delete the machine, and recreate the instance from a database backup.
    7. If it is safe, allow the system to continue to function;
      1. Complete any documentation relative to the security incident.
      2. Move to Phase V, Follow-up.
    8. If it is NOT safe to allow the system to continue operations, discontinue the system(s) operation and move to Phase III, Eradication.
    9. The individual completing this phase provides written communication to the SIRT.
  4. Continuously apprise Senior Management of progress.
  5. Continue to notify affected Customers and Partners with relevant updates as needed.

11.2.3 Eradication Phase (Technical)

The Eradication Phase represents the SIRT’s effort to remove the cause, and the resulting security exposures, that are now on the affected system(s).

  1. Determine symptoms and cause related to the affected system(s).
  2. Strengthen the defenses surrounding the affected system(s), where possible (a risk assessment may be needed and can be determined by the Security Officer). This may include the following:
    1. An increase in network perimeter defenses.
    2. An increase in system monitoring defenses.
    3. Remediation (“fixing”) any security issues within the affected system, such as removing unused services/general host hardening techniques.
  3. Conduct a detailed vulnerability assessment to verify all the holes/gaps that can be exploited have been addressed.
    1. If additional issues or symptoms are identified, take appropriate preventative measures to eliminate or minimize potential future compromises.
  4. Document the eradication steps.
  5. Update the documentation with the information learned from the vulnerability assessment, including the cause, symptoms, and the method used to fix the problem with the affected system(s).
  6. Apprise Senior Management of the progress.
  7. Continue to notify affected Customers and Partners with relevant updates as needed.
  8. Move to Phase IV, Recovery.

11.2.4 Recovery Phase (Technical)

The Recovery Phase represents the SIRT’s effort to restore the affected system(s) back to operation after the resulting security exposures, if any, have been corrected.

  1. The technical team determines if the affected system(s) have been changed in any way.
    1. If they have, the technical team restores the system to its proper, intended functioning (“last known good”).
    2. Once restored, the team validates that the system functions the way it was intended/had functioned in the past. This may require the involvement of the business unit that owns the affected system(s).
    3. If operation of the system(s) had been interrupted (i.e., the system(s) had been taken offline or dropped from the network while triaged), restart the restored and validated system(s) and monitor for behavior.
    4. If the system had not been changed in any way, but was taken offline (i.e., operations had been interrupted), restart the system and monitor for proper behavior.
    5. Update the documentation with the detail that was determined during this phase.
    6. Apprise Senior Management of progress.
    7. Continue to notify affected Customers and Partners with relevant updates as needed.
    8. Move to Phase V, Follow-up.

11.2.5 Follow-up Phase (Technical and Non-Technical)

The Follow-up Phase represents the review of the security incident to look for “lessons learned” and to determine whether the process that was taken could have been improved in any way. It is recommended all security incidents be reviewed shortly after resolution to determine where response could be improved. Timeframes may extend to one to two weeks post-incident. These processes may also be used to address events or precursors at the discretion of the Security Officer.

  1. Responders to the security incident (SIRT Team and technical security resource) meet to review the documentation collected during the security incident.
  2. Run a “post-mortem” process that minimally comprises the following:
    1. Evaluate the cost and impact of the security incident to Relevant using the documents provided by the SIRT and the technical security resource.
    2. Determine what could be improved.
    3. Communicate these findings to Senior Management for approval and for implementation of any recommendations made post-review of the security incident.
    4. Carry out recommendations approved by Senior Management; sufficient budget, time and resources should be committed to this activity.
    5. Close the security incident.

11.2.6 Periodic Evaluation

It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness. This also involves appropriate training of resources expected to respond to security incidents, as well as the training of the general population regarding Relevant’s expectation for them, relative to security responsibilities. The incident response plan is tested annually.

11.3 Security Incident Response Team (SIRT)

Current members of the Relevant SIRT:

12. Breach Policy

To provide guidance for breach notification when impressive or unauthorized access, acquisition, use and/or disclosure of the ePHI occurs. Breach notification will be carried out in compliance with the American Recovery and Reinvestment Act (ARRA)/Health Information Technology for Economic and Clinical Health Act (HITECH) as well as any other federal or state notification law.

The Federal Trade Commission (FTC) has published breach notification rules for vendors of personal health records as required by ARRA/HITECH. The FTC rule applies to entities not covered by HIPAA, primarily vendors of personal health records. The rule is effective September 24, 2009 with full compliance required by February 22, 2010.

The American Recovery and Reinvestment Act of 2009 (ARRA) was signed into law on February 17, 2009. Title XIII of ARRA is the Health Information Technology for Economic and Clinical Health Act (HITECH). HITECH significantly impacts the Health Insurance Portability and Accountability (HIPAA) Privacy and Security Rules. While HIPAA did not require notification when patient protected health information (PHI) was inappropriately disclosed, covered entities and business associates may have chosen to include notification as part of the mitigation process. HITECH does require notification of certain breaches of unsecured PHI to the following: individuals, Department of Health and Human Services (HHS), and the media. The effective implementation for this provision is September 23, 2009 (pending publication HHS regulations).

In the case of a breach, Relevant shall notify all affected Customers. It is the responsibility of the Customers to notify affected individuals.

12.1 Applicable Standards

12.1.1 Applicable Standards from the HITRUST Common Security Framework

12.1.2 Applicable Standards from the HIPAA Security Rule

12.2 Relevant Breach Policy

  1. Discovery of Breach: A breach of ePHI shall be treated as “discovered” as of the first day on which such breach is known to the organization, or, by exercising reasonable diligence would have been known to Relevant (includes breaches by the organization’s Customers, Partners, or subcontractors). Relevant shall be deemed to have knowledge of a breach if such breach is known or by exercising reasonable diligence would have been known, to any person, other than the person committing the breach, who is a workforce member or Partner of the organization. Following the discovery of a potential breach, the organization shall begin an investigation (see organizational policies for security incident response and/or risk management incident response) immediately, conduct a risk assessment, and based on the results of the risk assessment, begin the process to notify each Customer affected by the breach. Relevant shall also begin the process of determining what external notifications are required or should be made (e.g., Secretary of Department of Health & Human Services (HHS), media outlets, law enforcement officials, etc.)
  2. Breach Investigation: The Relevant Security Officer shall name an individual to act as the investigator of the breach (e.g., privacy officer, security officer, risk manager, etc.). The investigator shall be responsible for the management of the breach investigation, completion of a risk assessment, and coordinating with others in the organization as appropriate (e.g., administration, security incident response team, human resources, risk management, public relations, legal counsel, etc.) The investigator shall be the key facilitator for all breach notification processes to the appropriate entities (e.g., HHS, media, law enforcement officials, etc.). All documentation related to the breach investigation, including the risk assessment, shall be retained for a minimum of six years.
  3. Risk Assessment: For an acquisition, access, use or disclosure of ePHI to constitute a breach, it must constitute a violation of the HIPAA Privacy Rule. A use or disclosure of ePHI that is incident to an otherwise permissible use or disclosure and occurs despite reasonable safeguards and proper minimum necessary procedures would not be a violation of the Privacy Rule and would not qualify as a potential breach. To determine if an impermissible use or disclosure of ePHI constitutes a breach and requires further notification, the organization will need to perform a risk assessment to determine if there is significant risk of harm to the individual as a result of the impermissible use or disclosure. The organization shall document the risk assessment as part of the investigation in the incident report form noting the outcome of the risk assessment process. The organization has the burden of proof for demonstrating that all notifications to appropriate Customers or that the use or disclosure did not constitute a breach. Based on the outcome of the risk assessment, the organization will determine the need to move forward with breach notification. The risk assessment and the supporting documentation shall be fact specific and address:
    • Consideration of who impermissibly used or to whom the information was impermissibly disclosed;
    • The type and amount of ePHI involved;
    • The cause of the breach, and the entity responsible for the breach, either Customer, Relevant, or Partner.
    • The potential for significant risk of financial, reputational, or other harm.
  4. Timeliness of Notification: Upon discovery of a breach, notice shall be made to the affected Relevant Customers according to the timelines agreed to in the BAA with the affected Customer/Covered Entity. It is the responsibility of the organization to demonstrate that all notifications were made as required, including evidence demonstrating the necessity of delay.
  5. Delay of Notification Authorized for Law Enforcement Purposes: If a law enforcement official states to the organization that a notification, notice, or posting would impede a criminal investigation or cause damage to national security, the organization shall:
    • If the statement is in writing and specifies the time for which a delay is required, delay such notification, notice, or posting of the timer period specified by the official; or
    • If the statement is made orally, document the statement, including the identify of the official making the statement, and delay the notification, notice, or posting temporarily and no longer than 30 days from the date of the oral statement, unless a written statement as described above is submitted during that time.
  6. Content of the Notice: The notice shall be written in plain language and must contain the following information:
    • A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known;
    • A description of the types of unsecured protected health information that were involved in the breach (such as whether full name, Social Security number, date of birth, home address, account number, diagnosis, disability code or other types of information were involved), if known;
    • Any steps the Customer should take to protect Customer data from potential harm resulting from the breach.
    • A brief description of what Relevant is doing to investigate the breach, to mitigate harm to individuals and Customers, and to protect against further breaches.
    • Contact procedures for individuals to ask questions or learn additional information, which may include a toll-free telephone number, an e-mail address, a web site, or postal address.
  7. Methods of Notification: Relevant Customers will be notified via email and phone within the timeframe for reporting breaches, as outlined above.
  8. Maintenance of Breach Information/Log: As described above and in addition to the reports created for each incident, Relevant shall maintain a process to record or log all breaches of unsecured ePHI regardless of the number of records and Customers affected. The following information should be collected/logged for each breach (see sample Breach Notification Log):
    • A description of what happened, including the date of the breach, the date of the discovery of the breach, and the number of records and Customers affected, if known.
    • A description of the types of unsecured protected health information that were involved in the breach (such as full name, Social Security number, date of birth, home address, account number, etc.), if known.
    • A description of the action taken with regard to notification of patients regarding the breach.
    • Resolution steps taken to mitigate the breach and prevent future occurrences.
  9. Workforce Training: Relevant shall train all members of its workforce on the policies and procedures with respect to ePHI as necessary and appropriate for the members to carry out their job responsibilities. Workforce members shall also be trained as to how to identify and report breaches within the organization.
  10. Complaints: Relevant must provide a process for individuals to make complaints concerning the organization’s patient privacy policies and procedures or its compliance with such policies and procedures.
  11. Sanctions: The organization shall have in place and apply appropriate sanctions against members of its workforce, Customers, and Partners who fail to comply with privacy policies and procedures.
  12. Retaliation/Waiver: Relevant may not intimidate, threaten, coerce, discriminate against, or take other retaliatory action against any individual for the exercise by the individual of any privacy right. The organization may not require individuals to waive their privacy rights under as a condition of the provision of treatment, payment, enrollment in a health plan, or eligibility for benefits.

12.3 Relevant Platform Customer Responsibilities

  1. The Relevant Customer that accesses, maintains, retains, modifies, records, stores, destroys, or otherwise holds, uses, or discloses unsecured ePHI shall, without unreasonable delay and in no case later than 60 calendar days after discovery of a breach, notify Relevant of such breach. The Customer shall provide Relevant with the following information:
    • A description of what happened, including the date of the breach, the date of the discovery of the breach, and the number of records and Customers affected, if known.
    • A description of the types of unsecured protected health information that were involved in the breach (such as full name, Social Security number, date of birth, home address, account number, etc.), if known.
    • A description of the action taken with regard to notification of patients regarding the breach.
    • Resolution steps taken to mitigate the breach and prevent future occurrences.
  2. Notice to Media: Relevant Customers are responsible for providing notice to prominent media outlets at the Customer’s discretion.
  3. Notice to Secretary of HHS: Relevant Customers are responsible for providing notice to the Secretary of HHS at the Customer’s discretion.

12.4 Sample Letter to Customers in Case of Breach

[Date]

[Name] [Name of Customer] [Address 1] [Address 2] [City, State Zip Code]

Dear [Name of Customer]:

I am writing to you from Relevant Healthcare Technologies, Inc., with important information about a recent breach that affects your account with us. We became aware of this breach on [Insert Date] which occurred on or about [Insert Date]. The breach occurred as follows:

Describe event and include the following information:

Other Optional Considerations:

We will assist you in remedying the situation.

Sincerely,

Jacob Hodes
Co-founder - Relevant Healthcare Technologies, Inc.
jacob@relevant.healthcare
718-755-6853

13. Disaster Recovery Policy

Relevant maintains procedures to recover operations following a disruption resulting from a disaster. These procedures have the following objectives:

  1. Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:
    • Notification/Activation phase to detect and assess damage and to activate the plan;
    • Recovery phase to restore temporary IT operations and recover damage done to the original system;
    • Reconstitution phase to restore IT system processing capabilities to normal operations.
  2. Identify the activities, resources, and procedures needed to carry out Relevant processing requirements during prolonged interruptions to normal operations.
  3. Identify and define the impact of interruptions to Relevant systems.
  4. Assign responsibilities to designated personnel and provide guidance for recovering Relevant during prolonged periods of interruption to normal operations.
  5. Ensure coordination with other Relevant staff who will participate in the contingency planning strategies.
  6. Ensure coordination with external points of contact and vendors who will participate in the contingency planning strategies.

13.1 Applicable Standards

13.1.1 Applicable Standards from the HITRUST Common Security Framework

13.1.2 Applicable Standards from the HIPAA Security Rule

13.2 Line of Succession

The following order of succession to ensure that decision-making authority for the Relevant Contingency Plan is uninterrupted. The Security Officer is responsible for ensuring the safety of personnel and the execution of procedures documented within this Relevant Contingency Plan. If the Security Officer is unable to function as the overall authority or specifically delegate this responsibility to a successor, the Privacy Officer shall function as that authority. To provide contact initiation should the contingency plan need to be initiated, please use the contact list below.

13.4 Testing and Maintenance

The Security Officer shall establish criteria for validation/testing of a Contingency Plan, an annual test schedule, and ensure implementation of the test. This process will also serve as training for personnel involved in the plan’s execution. At a minimum the Contingency Plan shall be tested annually (within 365 days). The types of validation/testing exercises include tabletop and technical testing. Contingency Plans for all application systems must be tested at a minimum using the tabletop testing process. However, if the application system Contingency Plan is included in the technical testing of their respective support systems that technical test will satisfy the annual requirement.

13.4.1 Testing

Relevant conducts tabletop and functional tests in scheduled “Game Days.” The primary objective of Game Days is to ensure designated personnel are knowledgeable and capable of fulfilling notification requirements and restoring service in a timely manner in the event of an outage. The exercises simulate the occurrence of a specific crisis that can require technical responses like:

13.5 Disaster Recovery Procedures

13.5.1 Notification and Activation Phase

This phase addresses the initial actions taken to detect and assess damage inflicted by a disruption to Relevant. Based on the assessment of the Event, sometimes according to the Relevant Incident Response Policy, the Contingency Plan may be activated by either the Security Officer.

The notification sequence is listed below:

13.5.2 Recovery Phase

This section provides procedures for recovering the application in an alternate system, whereas other efforts are directed to repair damage to the original system and capabilities.

The following procedures are for recovering the Relevant infrastructure at the alternate host. Procedures are outlined per team required. Each procedure should be executed in the sequence it is presented to maintain efficient operations.

Recovery Goal: The goal is to rebuild Relevant infrastructure to a new production state.

The tasks outlines below are not sequential and some can be run in parallel.

  1. Contact Partners and Customers affected
  2. Assess damage to the environment
  3. Begin replication of new environment using automated and tested scripts
  4. Test new environment
  5. Test logging, security, and alerting functionality
  6. Assure systems are appropriately patched and up to date
  7. Deploy environment to production
  8. Update DNS to new environment

13.5.3 Reconstitution Phase

This section discusses activities necessary for restoring Relevant operations at the original or new site. The goal is to restore full operations within 24 hours of a disaster or outage. When the hosted data center at the original or new site has been restored, Relevant operations at the alternate site may be transitioned back. The goal is to provide a seamless transition of operations from the alternate site to the computer center.

  1. Original or New Site Restoration
    • Begin replication of new environment using automated and tested scripts
    • Test new environment
    • Test logging, security, and alerting functionality
    • Deploy environment to production
    • Assure systems are appropriately patched and up to date
    • Update DNS to new environment

14. Device & Media Controls

14.1 Applicable Standards

14.1.1 Applicable Standards from the HITRUST Common Security Framework

14.1.2 Applicable Standards from the HIPAA Security Rule

14.1.3 Removable Media

Relevant does not allow ePHI to be stored on removable media such as thumb drives, CD-ROMs, or external hard drives.

14.1.4 Disposal

The organization securely disposes media with sensitive information. Hard disks must be wiped with a secure method and approved by the Security Officer before disposal.

14.1.5 Re-use

Before a device is reused, even by another Relevant employee, its hard disk must be wiped with a secure method and approved by the Security Officer before reuse.

15. IDS Policy

In order to preserve the integrity of data that Relevant stores, processes, or transmits for Customers, Relevant implements strong intrusion detection tools and policies to proactively track and retroactively investigate unauthorized access. Relevant currently utilizes OSSEC to track file system integrity, monitor log data, and detect rootkit access.

15.1 Applicable Standards

15.1.1 Applicable Standards from the HITRUST Common Security Framework

15.1.2 Applicable Standards from the HIPAA Security Rule

15.2 Intrusion Detection Policy

  1. OSSEC is used to monitor and correlate log data from different systems on an ongoing basis. Reports generated by OSSEC are reviewed by the Security Officer on a monthly basis.
  2. OSSEC generates alerts to analyze and investigate suspicious activity or suspected violations.
  3. OSSEC monitors file system integrity and sends real time alerts when suspicious changes are made to the file system.
  4. Automatic monitoring is done to identify patterns that might signify the lack of availability of certain services and systems.
  5. New firewall rules and configuration changes are entered into Terraform if possible and tested before being pushed into production. All firewall and router rules are reviewed annually.

16. Vulnerability Scanning Policy

Relevant is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. Relevant utilizes Google’s Security Command Center tools to consistently scan, identify, and address vulnerabilities on our systems. We also utilize OSSEC on production systems for file integrity checking and intrusion detection.

16.1 Applicable Standards

16.1.1 Applicable Standards from the HITRUST Common Security Framework

16.1.2 Applicable Standards from the HIPAA Security Rule

16.1.3 Applicable Standards from from NYSDOH SSP Framework

RA-5 - Vulnerability Scanning

16.2 Vulnerability Scanning Policy

  1. Security Command Center management is performed by the Relevant Security Officer, or an authorized delegate of the Security Officer.
  2. The Security Command Center is used to monitor all internal IP addresses (servers, VMs, etc) on Relevant networks.
  3. Frequency of scanning is as follows:
    1. At least every 72 hours
  4. Reviewing Security Command Center reports and findings, as well as any further investigation into discovered vulnerabilities, is the responsibility of the Relevant Security Officer. The process for reviewing Security Command Center reports is outlined below:
    1. The Security Officer initiates the review of a Security Command Center Report by creating an Issue in the Relevant Compliance Management System.
    2. The Security Officer, or a Relevant Security Engineer assigned by the Security Officer, is assigned to review the Security Command Center Report.
    3. If new vulnerabilities are found during review, the process outlined below is used to test those vulnerabilities. Once those steps are completed, the Issue is then reviewed again.
    4. Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review.
    5. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
  5. In the case of new vulnerabilities, the following steps are taken:
    • All new vulnerabilities are verified manually to assure they are repeatable. Those not found to be repeatable are manually tested after the next vulnerability scan, regardless of if the specific vulnerability is discovered again.
    • Vulnerabilities that are repeatable manually are documented and reviewed by the Security Officer and Privacy Officer to see if they are part of the current risk assessment performed by Relevant.
    • Those that are a part of the current risk assessment are checked for mitigations.
    • Those that are not part of the current risk assessment trigger a new risk assessment, and this process is outlined in detail in the Relevant Risk Assessment Policy.
  6. All vulnerability scanning reports are retained for 6 years by Relevant. Vulnerability report review is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.
  7. Penetration testing is performed regularly as part of the Relevant vulnerability management policy.
    • External penetration testing is performed annually by a third party.
    • Penetration tests results are retained for 6 years by Relevant.
    • Internal penetration testing is monitored on an annual basis using the Quality Management System reporting to assess compliance with above policy.
  8. This vulnerability policy is reviewed on a quarterly basis by the Security Officer and Privacy Officer.

17. Data Integrity Policy

Relevant takes data integrity very seriously. As stewards and partners of Relevant Customers, we strive to assure data is protected from unauthorized access and that it is available when needed. The following policies drive many of our procedures and technical settings in support of the Relevant mission of data protection.

Production systems that create, receive, store, or transmit Customer data (hereafter “Production Systems”) must follow the guidelines described in this section.

17.1 Applicable Standards

17.1.1 Applicable Standards from the HITRUST Common Security Framework

17.1.2 Applicable Standards from the HIPAA Security Rule

17.2 Disabling Non-Essential Services

  1. All Production Systems must disable services that are not required to achieve the business purpose or function of the system.

17.3 Monitoring Log-in Attempts

  1. All access to Production Systems must be logged. This is done following the Relevant Auditing Policy.

17.4 Prevention of Malware on Production Systems

  1. All Production Systems must have OSSEC running, and set to scan system every 2 hours and at reboot to assure not malware is present. Detected malware is evaluated and removed.
  2. Virus scanning software is run on all Production Systems for anti-virus protection.
    • Hosts are scanned daily for malicious binaries in critical system paths.
    • The malware signature database is checked hourly and automatically updated if new signatures are available.
    • Logs of virus scans are maintained according to the requirements outlined in §8.6.
  3. All Production Systems are to only be used for Relevant business needs.

17.5 Patch Management

  1. Software patches and updates will be applied to all systems in a timely manner. In the case of routine updates, they will be applied after thorough testing. In the case of updates to correct known vulnerabilities, priority will be given to testing to speed the time to production. Critical security patches are applied within 30 days from testing and all security patches are applied within 90 days after testing.
  2. Administrators subscribe to mailing lists to ensure that they are using current versions of all Relevant-managed software on Production Systems.

17.6 Intrusion Detection and Vulnerability Scanning

  1. Production systems are monitored using IDS systems. Suspicious activity is logged and alerts are generated.
  2. Vulnerability scanning of Production Systems must occur on a predetermined, regular basis, no less than annually. Currently it is weekly. Scans are reviewed by Security Officer, with defined steps for risk mitigation, and retained for future reference.

17.7 Production System Security

  1. System, network, and server security is managed and maintained by the Security Officer in conjunction with the Dev Ops team.
  2. Up to date system lists and architecture diagrams are kept for all production environments.
  3. Access to Production Systems is controlled using centralized tools and two-factor authentication.

17.8 Production Data Security

  1. Relevant takes measures to reduce the risk of compromise of Production Data.
  2. Relevant implements and/or reviews controls designed to protect Production Data from improper alteration or destruction.
  3. Relevant ensures that confidential data is stored in a manner that supports user access logs and automated monitoring for potential security incidents.
  4. Relevant ensures Relevant Customer Production Data is segmented and only accessible to Customers authorized to access data.
  5. All Production Data at rest is stored on encrypted volumes, using encryption keys managed by Google, in order to leverage Google’s key management protocols, such as automated key rotation.
  6. Volume encryption keys and machines that generate volume encryption keys are protected from unauthorized access. Volume encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
  7. Encrypted volumes use AES encryption with a minimum of 256-bit keys, or keys and ciphers of equivalent or higher cryptographic strength.

17.9 Transmission Security

  1. All data transmission is encrypted end-to-end using encryption keys managed by Google (in the case of infrastructure within Google Cloud Platform) or by Relevant. Encryption is not terminated at the network endpoint, and is carried through to the application. The one exception to this is SMS messages that are sent via Twilio, which cannot be encrypted due to constraints in the protocol.
  2. Transmission encryption keys and machines that generate keys are protected from unauthorized access. Transmission encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
  3. Transmission encryption keys use a minimum of 2048-bit RSA keys, or keys and ciphers of equivalent or higher cryptographic strength (e.g., 256-bit AES session keys in the case of IPsec encryption).
  4. Transmission encryption keys are limited to use for one year and then must be regenerated.
  5. In the case of Relevant provided APIs, provide mechanisms to assure the person sending or receiving data is authorized to send and save data.
  6. System logs of all transmissions of Production Data access. These logs must be available for audit.

18. Data Retention Policy

Despite not being a requirement within HIPAA, Relevant understands and appreciates the importance of health data retention. Acting as a subcontractor, and at times a business associate, Relevant is not directly responsible for health and medical records retention as set forth by each state. Despite this, Relevant has created and implemented the following policy to make it easier for Relevant Customers to support data retention laws.

18.1 State Medical Record Laws

18.2 Data Retention Policy

19. Traffic Flow Policy

19.1 Applicable Standards

19.1.1 Applicable Standards from the NYSDOH SSP Framework

19.2 Traffic Flow Policies

Relevant manages the interface of each external telecommunication service within the information system boundary.

The confidentiality and integrity of the information being transmitted across each interface is protected by enforcing TLS for HTTP based connections and SSH system access.

A written traffic flow policy is maintained for each interface. Such policies deny network traffic by default and only allow defined exceptions. Any exception to the interface’s general traffic flow policy must be documented with the supporting mission or business need, including the expected duration of the need.

Any exception to the traffic flow policy must be reviewed at a frequency no less than every three hundred sixty-five (365) days, as well as prior to the implementation of any major new system. Exceptions that are no longer supported by an explicit mission/business need are retired.

20. Employees Policy

Relevant is committed to ensuring all workforce members actively address security and compliance in their roles at Relevant. As such, training is imperative to assuring an understanding of current best practices, the different types and sensitivities of data, and the sanctions associated with non-compliance.

20.1 Applicable Standards

20.1.1 Applicable Standards from the HITRUST Common Security Framework

20.1.2 Applicable Standards from the HIPAA Security Rule

20.1.3 Applicable Standards from NYSDOH SSP Framework

20.2 Employment Policies

  1. All new workforce members, including contractors, are given training on security policies and procedures, including operations security, within 30 days of employment.
    • Records of training are kept for all workforce members.
    • Current Relevant training is provided by hipaatraining.com.
    • Relevant maintains records of employees successful completion of the courses provided by hipaatraining.com.
    • Employees must complete this training before accessing production systems containing ePHI.
  2. All workforce members are granted access to formal organizational policies, which include the sanction policy for security violations.
  3. Relevant does not allow mobile devices to connect to any of its production networks.
  4. All workforce members are educated about the approved set of tools to be installed on workstations.
  5. All new workforce members are given HIPAA training within 30 days of beginning employment. Training includes HIPAA reporting requirements, including the ability to anonymously report security incidents, and the levels of compliance and obligations for Relevant and its Customers and Partners.
  6. All remote (teleworking) workforce members are trained on the risks, the controls implemented, their responsibilities, and sanctions associated with violation of policies. Additionally, remote security is maintained through the use of VPN tunnels for all access to production systems with access to ePHI data.
  7. All Relevant-purchased and -owned computers are to display this message at login and when the computer is unlocked: By logging in, unlocking, or using this computer, you acknowledge that you have completed Relevant’s HIPAA training, and have reviewed and agree to follow Relevant’s policies and procedures..
  8. Employees may only use Relevant-purchased and -owned workstations for accessing production systems with access to ePHI data.
    • Any workstations used to access production systems must be configured as prescribed in §7.8.
    • Any workstations used to access production systems must have virus protection software installed, configured, and enabled.
    • Relevant may monitor access and activities of all users on workstations and production systems in order to meet auditing policy requirements (§8).
  9. Access to internal Relevant systems can be requested using the procedures outlined in §7.2. All requests for access must be granted by the Relevant Security Officer or Privacy Officer.
  10. Request for modifications of access for any Relevant employee can be made using the procedures outlined in §7.2.
  11. Employees are required to cooperate with federal and state investigations.
    • Employees must not interfere with investigations through willful misrepresentation, omission of facts, or by the use of threats against any person.
    • Employees found to be in violation of this policy will be subject to sanctions as described in §5.3.3.

20.3 Issue Escalation

Security incidents, particularly those involving ePHI, are handled using the process described in §11.2. If the incident involves a breach of ePHI, the Security Officer will manage the incident using the process described in §12.2. Refer to §11.2 for a list of sample items that can trigger Relevant’s incident response procedures; if you are unsure whether the issue is a security incident, contact the Security Officer immediately.

It is the duty of that owner to follow the process outlined below:

  1. Create an Issue in the Relevant Compliance Management System.
  2. The Issue is investigated, documented, and, when a conclusion or remediation is reached, it is moved to Review.
  3. The Issue is reviewed by another member of the Escalation Team. If the Issue is rejected, it goes back for further evaluation and review.
  4. If the Issue is approved, it is marked as Done, adding any pertinent notes required.
  5. The workforce member that initiated the process is notified of the outcome via email.

21. Approved Tools Policy

Relevant utilizes a suite of approved software tools for internal use by workforce members. These software tools are either self-hosted, with security managed by Relevant, or they are hosted by a Subcontractor with appropriate business associate agreements in place to preserve data integrity. Use of other tools requires approval from Relevant leadership.

21.1 List of Approved Tools

21.1.1 PHI-approved Tools

21.1.2 PHI-restricted Tools

21.1.3 Collaborative Computing Tools

The following collaborative computing tools are authorized for use by Relevant employees:

The above tools are authorized to be used only via the following mechanisms:

The above tools are authorized to be used only for the execution of essential job functions.

All other collaborative computer devices or tools (including networked whiteboards, cameras, or microphones) are prohibited for use, unless they are explicitly authorized, in writing, and documented in the Relevant Compliance Management System, by the Security Officer or their designee. If any such additional collaborative computing devices or tools are authorized, the authorization must identify the allowed mechanisms, allowed purpose, and the information system upon which the tools can be used.

Relevant prohibits the remote activation of collaborative computing devices or tools.

Relevant requires that any mechanism used to activate a collaborative computing tool provide an explicit indication of use to users physically present at the collaborative computing device. Such indication of use may include an indicator light or specific text that appears on screen. If the device or tool does not have the means to indicate that it is in use, Relevant must provide a manual means to do so before any such tool is approved for use.

22. 3rd Party Policy

Relevant makes every effort to assure all 3rd party organizations are compliant and do not compromise the integrity, security, and privacy of Relevant or Relevant Customer data. 3rd Parties include Customers, Partners, Subcontractors, and Contracted Developers.

22.1 Applicable Standards

22.1.1 Applicable Standards from the HITRUST Common Security Framework

22.1.2 Applicable Standards from the HIPAA Security Rule

22.2 Policies to Assure 3rd Parties Support Relevant Compliance

  1. Relevant does not allow 3rd party access to production systems containing ePHI.
  2. All connections and data in transit between the Relevant Platform and 3rd parties are encrypted end to end.
  3. A standard business associate agreement with Customers and Partners is defined and includes the required security controls in accordance with the organization’s security policies. Additionally, responsibility is assigned in these agreements.
  4. Relevant has Service Level Agreements (SLAs) with Subcontractors with an agreed service arrangement addressing liability, service definitions, security controls, and aspects of services management.
    • Subcontractors must coordinate, manage, and communicate any changes to services provided to Relevant.
    • Changes to 3rd party services are classified as configuration management changes and thus are subject to the policies and procedures described in §9; substantial changes to services provided by 3rd parties will invoke a Risk Assessment as described in §4.2.
    • Relevant utilizes monitoring tools to regularly evaluate Subcontractors against relevant SLAs.
  5. No Relevant Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties.
  6. Relevant does not outsource software development.
  7. Relevant maintains and annually reviews a list all current Partners and Subcontractors.
    • The list of current Partners and Subcontractors is maintained by the Relevant Privacy Officer, includes details on all provided services (along with contact information), and is recorded in §1.4.
    • The annual review of Partners and Subcontractors is conducted as a part of the security, compliance, and SLA review referenced below.
  8. Relevant assesses security, compliance, and SLA requirements and considerations with all Partners and Subcontractors. This includes annual assessment of SOC2 reports for all Relevant infrastructure partners.
    • Relevant leverages recurring calendar invites to assure reviews of all 3rd party services are performed annually. These reviews are performed by the Relevant Security Officer and Privacy Officer. The process for reviewing 3rd party services is outlined below:
      1. The Security Officer initiates the SLA review by creating an Issue in the Relevant Compliance Management System.
      2. The Security Officer, or Privacy Officer, is assigned to review the SLA and performance of 3rd parties. The list of current 3rd parties, including contact information, is also reviewed to assure it is up to date and complete.
      3. SLA, security, and compliance performance is documented in the Issue.
      4. Once the review is completed and documented, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
  9. Regular review is conducted as required by SLAs to assure security and compliance. These reviews include reports, audit trails, security events, operational issues, failures and disruptions, and identified issues are investigated and resolved in a reasonable and timely manner.
  10. Any changes to Partner and Subcontractor services and systems are reviewed before implementation.
  11. For all partners, Relevant reviews activity annually to assure partners are in line with SLAs in contracts with Relevant.
  12. SLA review is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.
  13. The 3rd Party Assurance process is reviewed annually and updated to include any necessary changes.
  14. Changes to the 3rd Party Assurance process will also be made on an ad-hoc basis in cases where operational changes require it or if the process is found lacking.

23. Key Definitions

  1. Any unintentional acquisition, access or use of PHI by a workforce member or person acting under the authority of a Covered Entity (CE) or Business Associate (BA) if such acquisition, access, or use was made in good faith and within the scope of authority and does not result in further use or disclosure in a manner not permitted under the Privacy Rule.
  2. Any inadvertent disclosure by a person who is authorized to access PHI at a CE or BA to another person authorized to access PHI at the same CE or BA, or organized health care arrangement in which the CE participates, and the information received as a result of such disclosure is not further used or disclosed in a manner not permitted under the Privacy Rule.
  3. A disclosure of PHI where a CE or BA has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information.

24. Citations

Relevant’s HIPAA Policies and Procedures are based on Datica’s open source compliance policies, which are licensed under CC BY-SA 4.0.