Cordata Policy Docs

    ClearDATA# Introduction

    Cordata Healthcare Innovations, LLC (“Cordata”) 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 software used by health providers, Cordata 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 Cordata to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for Cordata Customers.

    Cordata provides secure and compliant cloud-based software.

    Cordata Organizational Concepts

    The infrastructure environment is hosted on AWS (administered by ClearDATA) ClearDATA. The network components and supporting network infrastructure is contained within the ClearDATA infrastructure and managed by ClearDATA. Cordata does not have physical access into the network components. The Cordata environment consists of AWS firewalls, Linux Servers, PostgreSQL servers, Logstash logging servers, Linux Ubuntu monitoring servers, OSSEC IDS services, AWS ECS containers, RDS databases, and developer tools servers running on Linux Ubuntu.

    Within the Cordata Platform, and within the ClearDATA infrastructure, all data transmission is encrypted and all hard drives are encrypted so data at rest is also encrypted; this applies to all servers - those hosting Docker containers, databases, APIs, log servers, etc. Cordata assumes all data may contain ePHI, even though our Risk Assessment does not indicate this is the case, and provides appropriate protections based on that assumption.

    Additionally, the data is segmented in such a way that each customer is only able to see that customer’s data at a database level security control. Cordata has implemented strict logical access controls so that only authorized personnel are given access to the internal management servers. The environment is configured so that data is transmitted from the load balancers to the application servers over an SSL encrypted session.

    The App server is externally facing and accessible via the Internet. The database servers, where the ePHI resides, are located on the internal Cordata network and can only be accessed directly over an SSH connection. The access to the internal database is restricted to a limited number of personnel and strictly controlled to only those personnel with a business justified reason. Remote access to the internal servers is not accessible except through the load balancers.

    Version Control

    Policies are checked into Github for source control.

    Policies were last reviewed and updated February 7, 2022

    3rd Party Policy

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

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Policies to Assure 3rd Parties Support Cordata Compliance

    1. The following steps are required before 3rd parties are granted access to any Cordata systems:
      • Due diligence with the 3rd party;
      • Controls implemented to maintain compliance;
      • Written agreements, with appropriate security requirements, are executed.
    2. All connections and data in transit between the Cordata Platform and 3rd parties are encrypted end to end.
    3. Access granted to external parties is limited to the minimum necessary and granted only for the duration required.
    4. 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.
    5. Cordata has Service Level Agreements (SLAs) with Subcontractors with an agreed service arrangement addressing liability, service definitions, security controls, and aspects of services management.
      • Cordata utilizes monitoring tools to regularly evaluate Subcontractors against relevant SLAs.
    6. Third parties are unable to make changes to any Cordata infrastructure without explicit permission from Cordata. Additionally, no Cordata Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties.
    7. Whenever outsourced development is utilized by Cordata, all changes to production systems will be approved and implemented by Cordata workforce members only. All outsourced development requires a formal contract with Cordata.
    8. Cordata maintains and annually reviews a list all current Partners and Subcontractors.
    9. Cordata assesses security requirements and compliance considerations with all Partners and Subcontracts.
    10. 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.
    11. Any changes to Partner and Subcontractor services and systems are reviewed before implementation.
    12. For all partners, Cordata reviews activity annually to assure partners are in line with SLAs in contracts with Cordata.

    ClearDATA#Administrative Safeguards (see 164.308)

    Taken directly from the wording of the Security Rule, administrative safeguards are administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect electronic protected health information and to manage the conduct of the covered entity’s workforce in relation to the protection of that information.

    There aren’t specific security settings in this section, and the most important area covered is the risk assessment. The risk assessment is a fundamental process for any organization that wants to become compliant.

    Security Management Process - 164.308(a)(1)(i)

    Cordata has a risk management policy that defines the risk analysis and risk management process. This policy is operationalized with processes to conduct regularly risk assessments. Cordata uses NIST800-30 and 800-26 for performing risk analysis. Our policy begins with an inventory of all Cordata systems, mapping of where ePHI is processed, transmitted, or stored, identification of threats, risks, and likelihood, and the mitigation of risks. Policies address risk inherent within the environment and mitigating the risk to an acceptable and reasonable level.

Cordata has a Sanction Policy that has sanctions for employees not adhering to certain policies, and for specifically violating HIPAA rules.

Policies and procedures address the requirements of monitoring and logging system level events and actions taken by individuals within the environment. All requests into and out of the Cordata network are logged, as well as all system events. Cordata, has implemented multiple logging and monitoring solutions to track events within their environment and to monitor for certain types of behavior. Log data is regularly reviewed. Additionally, proactive alerts are enabled and triggered based on certain suspicious activity.
    Standard Description
    Risk Analysis (Req) Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic PHI held by the covered entity.
    Risk Management (Req) Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with Sec. 164.306(a) [Security standards: General rules; (a) General requirements].
    Sanction Policy (Req) Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity.
    Information System Activity Review (Req) Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.

    Assigned Security Responsibility - 164.308(a)(2)

    Cordata has formally assigned and documented its security officer. Our security officer is Jon Stonis. He can be reached by email at jon.stonis@cordatahealth.com.
    Standard Description
    Assigned Security Responsibility (Req) Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the entity.

    Workforce Security - 164.308(a)(3)(i)

    Cordata has policies in place that require workforce members requesting access to ePHI to submit an authorization form that is signed and acknowledges their responsibility of safeguarding ePHI. The form must also be approved by the Security Officer. Once signed and approved, then the individual will be provisioned access to systems deemed business necessary. All Access to ePHI is based on minimum necessary requirements and least privilege.

Cordata policies define the immediate removal of access once an employee has been terminated, with the Security Officer responsible for terminating the access. Once HR initiates the termination process the termination checklist is referenced to ensure necessary actions are taken to remove systems and facilities access.
    Standard Description
    Authorization and/or Supervision (A) Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.
    Workforce Clearance Procedure (A) Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.
    Termination Procedures (A) Implement procedures for terminating access to electronic protected health information when the employment of a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) [Workforce Clearance Procedures] of this section.

    Information Access Management - 164.308(a)(4)(i)

    Cordata does not perform the functions of a Healthcare Clearinghouse so aspects of this section are not applicable.

The security officer determines the roles necessary for each system and application. When access is needed to Cordata infrastructure, a request and acknowledgement form is signed and then approved by the Security Officer.

Cordata has a formal process for requesting additional access to ePHI, and again Cordata customers must approve all requests concerning ePHI.
    Standard Description
    Isolating Health care Clearinghouse Function (Req) If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.
    Access Authorization (A) Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.
    Access Establishment and Modification (A) Implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process.

    Security Awareness and Training - 164.308(a)(5)(i)

    Cordata has a Security Awareness training policy in place that requires new employees and current employees to conduct training upon hire and annually thereafter. Minimum training is done annually, with regularly informal security and compliance traning done every other week.

Cordata proactively assesses and tests for malicious software within their environment, both infrastructure and workstations. Members of the Cordata team monitor bug and vulnerability lists to assure they remain up to date.

Cordata is monitoring and logging successful and unsuccessful log-in attempts to the servers within its environment and policies are in place requiring audit logging, which includes login attempts.

Password configurations are set to require that passwords are a minimum of 8 character length, 90 day password expiration, account lockout after 5 invalid attempts, password history of last 4 passwords remembered, and account lockout after 30 minutes of inactivity.
    Standard Description
    Security Reminders (A) Periodic security updates to all members of Cordata, Inc.
    Protection from Malicious Software (A) Procedures for guarding against, detecting, and reporting malicious software.
    Log-in Monitoring (A) Procedures for monitoring log-in attempts and reporting discrepancies.
    Password Management (A) Procedures for creating, changing, and safeguarding passwords.

    Security Incident Procedures - 164.308(a)(6)(i)

    Cordata has implemented a formal incident response plan (IRP), which discusses the procedures for identifying, responding to, and escalating suspected and confirmed security breaches. Cordata has implemented an incident response team for the purposes of dealing with potential security breaches. The IRP has specific types of incidents to look out for, as well as some common types of incidents that are monitored for within the environment.
    Standard Description
    Response and Reporting (Req) Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes.

    Contingency Plan - 164.308(a)(7)(i)

    Cordata has inherited the Backup and Recovery Policy from their platform-as-a-service partner, ClearDATA that defines the data backup strategy including: Schedule, associated responsibilities, and any risk-assessed exclusion to the backup schedule.

Cordata has a formal Disaster Recovery plan to ensure the efficient recovery of critical business data and systems in the event of a disaster. The Disaster Recovery (DR) plan includes specific technical procedures necessary to reinstate the infrastructure and data to allow critical business functions to continue business operations after a disaster has occurred. Additionally, the Cordata DR plan includes requirements for performing annual testing of the DR plan to ensure its effectiveness.

Cordata has a DR plan, or a a Business Continuity Plan (BCP), to aid in the efficient recovery of critical business functions after a disaster has been declared. The BCP goes into effect after facility outage of 24 hours. The BCP identifies critical information necessary to resume business operations such as: Hardware/software requirements, recovery time objectives, forms, employee/vendor contact lists, alternate working procedures, emergency access procedures, and a data and application criticality analysis. The BCP includes an Emergency Mode Operations Plan that addresses the access and protection of ePHI while operating in emergency mode.

The DR and BPC plans are reviewed and tested annually or whenever significant infrastructure changes occur.

Cordata has a performed an applications and data criticality analysis that details what systems and application need be recovered and their specific order in the recovery process.
    Standard Description
    Data Backup Plan (Req) Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.
    Disaster Recovery Plan (Req) Establish (and implement as needed) procedures to restore any loss of data.
    Emergency Mode Operation Plan (Req) Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic PHI while operating in emergency mode.
    Testing and Revision Procedure (A) Implement procedures for periodic testing and revision of contingency plans.
    Applications and Data Criticality Analysis (A) Assess the relative criticality of specific applications and data in support of other contingency plan components.

    Evaluation - 164.308(a)(8)

    Cordata has formal internal policies and procedures for conducting periodic technical and non-technical testing. These define procedures for performing quarterly internal and external vulnerability scanning, as well as annual penetration testing. Vulnerability scanning is performed with any major changes in infrastructure. Additionally, non-technical evaluations occur on an annual basis to ensure that the security posture of Cordata is at the defined level, approved by management, and communicated down to Cordata employees.
    Standard Description
    Evaluation (Req) Perform a periodic technical and non-technical evaluation, based initially upon the standards implemented under this rule and subsequently, in response to environmental or operational changes affecting the security of electronic PHI that establishes the extent to which an entity’s security policies and procedures meet the requirements of this subpart.

    Business Associate Contracts and Other Arrangement - 164.308(b)(1)

    Cordata has a formalized template, as well as policies in place regarding Business Associate Agreements and written contracts. Cordata has engaged a third part provider for hosting responsibilities and has written attestations of safeguarding its data. Additionally, Cordata performs due diligence in assuring that third party providers they select go through their due diligence process and provide services consistent with the ClearDATA security and compliance posture.
    Standard Description
    Written Contract or Other Arrangement (Req) A covered entity, in accordance with § 164.306 [Security Standards: General Rules], may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity’s behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a) [Business Associate Contracts or Other Arrangements] that the business associate will appropriately safeguard the information. Document the satisfactory assurances required by paragraph (b)(1) [Business Associate Contracts and Other Arrangements] of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of § 164.314(a) [Business Associate Contracts or Other Arrangements].

    Approved Tools Policy

    Cordata utilizes a suite of approved software tools for internal use by workforce members. These software tools are either self-hosted, with security managed by Cordata, 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 Cordata leadership.

    List of Approved Tools

    Auditing Policy

    Cordata shall audit access and activity of electronic protected health information (ePHI) applications and systems in order to ensure compliance. 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. Audit activities may be limited by application, system, and/or network auditing capabilities and resources. Cordata 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 Cordata to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, Cordata shall audit access and activity to detect, report, and guard against:

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

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Auditing Policies

    1. Responsibility for auditing information system access and activity is assigned to Cordata’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.).
      • All connections to Cordata are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
    2. Cordata’s auditing processes shall address access and activity at the following levels listed below. Auditing processes may address date and time of each log-on attempt, date and time of each log-off attempt, devices used, functions performed, etc.
      • User: User level audit trails generally monitor and log all commands directly initiated by the user, all identification and authentication attempts, and data and services accessed.
      • Application: Application level audit trails generally monitor and log all user activities, including data accessed and modified and specific actions.
      • System: System level audit trails generally monitor and log user activities, applications accessed, and other system defined specific actions.
      • Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities.
    3. Cordata shall log all incoming and outgoing traffic to into and out of its environment. This includes all successful and failed attempts at data access and editing. Data associated with this data will include origin, destination, time, and other relevant details that are available to Cordata.
    4. Cordata utilizes OSSEC to scan all systems for malicious and unauthorized software every 2 hours and at reboot of systems. Alerts from OSSEC are sent to the centralized logging service that we use.
    5. Cordata leverages process monitoring tools throughout its environment.
    6. Cordata uses OSSEC to monitor the integrity of log files by utilizing OSSEC System Integrity Checking capabilities.
    7. Cordata shall identify “trigger events” or criteria that raise awareness of questionable conditions of viewing of confidential information. The “events” may be applied to the entire Cordata Platform or may be specific to a Customer, partner, business associate, Platform Add-on or application (See Listing of Potential Trigger Events below).
    8. In addition to trigger events, Cordata utilizes OSSEC log correlation functionality to proactively identify and enable alerts based on log data.
    9. Logs are reviewed weekly by Security Officer.
    10. Cordata’s Security Officer and Privacy Officer are authorized to select and use auditing tools that are designed to detect network vulnerabilities and intrusions. Such tools are explicitly prohibited by others, including Customers and Partners, without the explicit authorization of the Security Officer. These tools may include, but are not limited to:
      • Scanning tools and devices;
      • Password cracking utilities;
      • Network “sniffers.”
      • Passive and active intrusion detection systems.
    11. The process for review of audit logs, trails, and reports shall include:
      • Description of the activity as well as rationale for performing the audit.
      • Identification of which Cordata workforce members will be responsible for review (workforce members shall not review audit logs that pertain to their own system activity).
      • Frequency of the auditing process.
      • Determination of significant events requiring further review and follow-up.
      • Identification of appropriate reporting channels for audit results and required follow-up.
    12. Vulnerability testing software may be used to probe the network to identify what is running (e.g., operating system or product versions in place), whether publicly-known vulnerabilities have been corrected, and evaluate whether the system can withstand attacks aimed at circumventing security controls.
      • Testing may be carried out internally or provided through an external third-party vendor. Whenever possible, a third party auditing vendor should not be providing the organization IT oversight services (e.g., vendors providing IT services should not be auditing their own services - separation of duties).
      • Testing shall be done on a routine basis, currently monthly.
    13. 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 patches are applied within 90 days after testing.

    Audit Requests

    1. A request may be made for an audit for a specific cause. The request may come from a variety of sources including, but not limited to, Privacy Officer, Security Officer, Customer, Partner, or an Application owner or application user.
    2. A request for an audit for specific cause must include time frame, frequency, and nature of the request. The request must be reviewed and approved by Cordata’s Privacy or Security Officer.
    3. A request for an audit must be approved by Cordata’s Privacy Officer and/or Security Officer before proceeding. Under no circumstances shall detailed audit information be shared with parties without proper permissions and access to see such data.
      • Should the audit disclose that a workforce member has accessed ePHI inappropriately, the minimum necessary/least privileged information shall be shared with Cordata’s Security Officer to determine appropriate sanction/ corrective disciplinary action.
      • Only de-identified information shall be shared with Customer or Partner regarding the results of the investigative audit process. This information will be communicated to the appropriate personnel by Cordata’s Privacy Officer or designee. Prior to communicating with customers and partners regarding an audit, it is recommended that Cordata consider seeking risk management and/or legal counsel.

    Review and Reporting of Audit Findings

    1. Audit information that is routinely gathered must be reviewed in a timely manner, currently monthly, by the responsible workforce member(s).
    2. The reporting process shall allow for meaningful communication of the audit findings to those workforce members, Customers, or Partners requesting the audit.
      • Significant findings shall be reported immediately in a written format. Cordata’s security incident response form may be utilized to report a single event.
      • Routine findings shall be reported to the sponsoring leadership structure in a written report format.
    3. Reports of audit results shall be limited to internal use on a minimum necessary/need-to-know basis. Audit results shall not be disclosed externally without administrative and/or legal counsel approval.
    4. Security audits constitute an internal, confidential monitoring practice that may be included in Cordata’s performance improvement activities and reporting. Care shall be taken to ensure that the results of the audits are disclosed to administrative level oversight structures only and that information which may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports (individually-identifiable e PHI shall not be included in the reports).
    5. Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the responsible workforce members, Customers, and/or Partners.

    Auditing Customer and Partner Activity

    1. Periodic monitoring of Customer and Partner activity shall be carried out to ensure that access and activity is appropriate for privileges granted and necessary to the arrangement between Cordata and the 3rd party. Cordata will make every effort to assure Customers and Partners do not gain access to data outside of their own Environments.
    2. If it is determined that the Customer or Partner has exceeded the scope of access privileges, Cordata’s leadership must remedy the problem immediately.
    3. If it is determined that a Customer or Partner has violated the terms of the HIPAA business associate agreement or any terms within the HIPAA regulations, Cordata must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.

    Audit Log Security Controls and Backup

    1. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy.
    2. All audit logs are encrypted in transit and at rest to control access to the content of the logs. For PaaS Customers, it is the responsibility of the Customer to encrypt log data before it is sent to Cordata Logging Service.
    3. Audit logs shall be stored on a separate system to minimize the impact auditing may have on the privacy system and to prevent access to audit trails by those with system administrator privileges. This is done to apply the security principle of “separation of duties” to protect audit trails from hackers.

    Workforce Training, Education, Awareness and Responsibilities

    1. Cordata workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI. Cordata’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. Cordata 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.
    2. Cordata Customers are provided with necessary information to understand Cordata auditing capabilities, as PaaS Customers of ClearDATA, Cordata is able to choose the level of logging and auditing that ClearDATA will implement on Cordata’s behalf.

    External Audits of Information Access and Activity

    1. Prior to contracting with an external audit firm, Cordata shall:
      • Outline the audit responsibility, authority, and accountability;
      • Choose an audit firm that is independent of other organizational operations;
      • Ensure technical competence of the audit firm staff;
      • Require the audit firm’s adherence to applicable codes of professional ethics;
      • Obtain a signed HIPAA business associate agreement;
      • Assign organizational responsibility for supervision of the external audit firm.

    Retention of Audit Data

    1. Audit logs shall be maintained based on organizational needs. There is no standard or law addressing the retention of audit log/trail information. Retention of this information shall be based on: A. Organizational history and experience. B. Available storage space.
    2. Reports summarizing audit activities shall be retained for a period of six years.
    3. Log data is currently retained and readily accessible for a 1-month period.
    4. For Paas Customers, they choose the length of backup retention and availability that ClearDATA will implement and enforce.

    Potential Trigger Events

    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, Cordata shall notify all affected Customers. It is the responsibility of the Customers to notify affected individuals.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Cordata 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 Cordata (includes breaches by the organization’s Customers, Partners, or subcontractors). Cordata 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. Cordata 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 Cordata 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. A template breach log is located here.
    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, Cordata, 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 Cordata Customers no later than 4 hours after the discovery of the breach. 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 Cordata 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: Cordata 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, Cordata 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: Cordata 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: Cordata 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: Cordata 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.

    Cordata Customer Responsibilities

    1. The Cordata 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 Cordata of such breach. The Customer shall provide Cordata 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: Cordata Customers are responsible for providing notice to prominent media outlets at the Customer’s discretion.
    3. Notice to Secretary of HHS: Cordata Customers are responsible for providing notice to the Secretary of HHS at the Customer’s discretion.

    Sample Letter to Customers in Case of Breach

    [Date]

    [Name here] [Address 1 Here] [Address 2 Here] [City, State Zip Code]

    Dear [Name of Customer]:

    I am writing to you from Cordata Healthcare Innovations, LLC 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: A. A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known. B. 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. C. Any steps the Customer should take to protect themselves from potential harm resulting from the breach. D. A brief description of what Cordata is doing to investigate the breach, to mitigate harm to individuals, and to protect against further breaches. E. Contact procedures for individuals to ask questions or learn additional information, which includes a toll-free telephone number, an e-mail address, web site, or postal address.

    Other Optional Considerations:

    We will assist you in remedying the situation.

    Sincerely,

    Gary Winzenread CEO - Cordata, Inc gary.winzenread@cordatahealth.com xxx-xxx-xxxx

    Configuration Management Policy

    Cordata standardizes and automates configuration management through the use of Ansible scripts as well as documentation of all changes to production systems and networks. Ansible automatically configures all Cordata systems according to established and tested policies, and is used as part of our Disaster Recovery plan and process.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Configuration Management

    1. Ansible is used to standardize and automate configuration management.
    2. OSSEC is used to scan systems every 2 hours and on reboot. These scans capture file system changes and also unauthorized or malicious software.
    3. No systems are deployed into Cordata environments without approval of the Cordata Security Officer.
    4. All changes to production systems, network devices, and firewalls are approved by the Cordata Security Officer before they are implemented. Additionally, all changes are tested before they are implemented in production.
    5. An up-to-date inventory of systems is maintained using Google spreadsheets and architecture diagrams hosted on Google Apps and Box. All systems are categorized as production and utility to differentiate based on criticality.
    6. Clocks are synchronized across all systems using NTP. Modifying time data on systems is restricted.
    7. All front end functionality (developer dashboards and portals) is separated from backend (database and app servers) systems by being deployed on separate servers and in different Virtual Private Networks.
    8. All software and systems are tested using unit tests and end to end tests.
    9. All committed code is reviewed using pull requests (on Github) to assure software code quality and proactively detect potential security issues in development.
    10. Cordata utilizes development and staging environments that mirror production to assure proper function.
    11. Cordata also deploys environments locally using Vagrant to assure functionality before moving to staging or production.

    Change Management Policy

    Overview

    Change management generally includes the following steps: * Planning * Evaluation * Review * Approval * Communication * Implementation (Deployment) * Documentation * Post-change review NOTE: This document is subject is change. Change management / audit of changes is found in github where the source of policy.cordatahealth.com is located. This document is available live by accessing the aforementioned url.

    Scope

    This policy applies to all changes to architecture, tools, IT services and software development provided by Cordata Healthcare Innovations, LLC.

    Security

    While our overall security strategy is outlined in other documents located on policy.cordatahealth.com, we find it necessary to include some general information about this topic in the Change Management policy. The following is provided by both AWS and ClearDATA.

    Policy

    All changes to IT services must follow a structured process to ensure that appropriate planning and execution occur. There are three types of changes we will cover. * Standard changes. Minimal changes required to support day-to-day operations - e.g. divisional configuration in setting up a client. * Normal Change (typically applies to our quarterly deployments). * Emergency Changes (hotfixes and/or production fixes) - A change that must be introduced as soon as possible due to likely negative service impacts. There may be fewer people involved in the change management process review, and the change assessment may involve fewer steps due to the urgent nature of the issue.

    Data Change Audit

    All data changes to our system are 100% audited. We maintain a before / after audit of all database tables contained within our system to ensure that all auditing / change control is maintained. Regular backups of all data is maintained by ClearDATA according to their documented data retention policies.

    Policy for Standard, Normal and Emergency Changes

    Standard production changes.

    Software Development - Change Management Process

    All software development lifecycle changes are managed using clubhouse.io as our Agile / Process Engineering tool. Product Management outlines the priorities for a given release (e.g. 8.4) and has them approved by the Senior Management Team. Product Management and the Sr. Director of Product Engineering meet to break the priorities into agile “stories”. These stories are then broken into sprints (2 week increments). A developer begins an approved story within a 2-week sprint time period. During this time, this person (the developer) will checkout code from github (our approved organizational code repository). Any work done during this timeframe is on the local device (e.g. desktop computer). Upon code completion, a developer submits a pull request. Two things must occur at this time. 1) A mandatory peer code review is completed and 2) an authorized branch admin will commit the code once the code review is completed. These constraints are configured and enforced utilizing github permissions according to job responsibility. This ensures that no code makes it into our pipeline without being examined first. All changes are 100% audited through our source control management tool (github). All changes must be tested by the Cordata QA department. A clubhouse.io card is moved into the QA team’s lane where they pick up the work and complete testing. If bugs are found, a card is introduced and someone from the development team must fix it before the item is marked as done. Prior to the release into staging / production, the team performs Regression Testing on the entire suite of applications to ensure a quality release to our Customers. Once a release cycle is completed, the release branch is then merged into the mainline branch and released into staging and then production according to the normal process.

    Software Release Process (Deployments)

    All software utilized by Cordata’s staging or production systems is located within AWS and utilizes ClearDATA’s infrastructure for security. We are a cloud-based, web application provider. All software and systems are fully HIPAA compliant and HITRUST certified via ClearDATA. The normal release process works as follows: Only a few authorized individuals can access the AWS account utilizing the aws CLI for deployment. These individuals are approved and granted access by means of the Sr. Director of Product Engineering. Upon full approval by QA and Product Management, an approved individual will execute the necessary steps to upgrade our server environment. We use Amazon ECS / Docker Containers which allows us to do real-time upgrades without any downtime to the system. All deployment changes are audited. Each deployment requires an explanation - the deployment activity is then logged into a database and made available in report form for audit purposes.

    Change Management Roles

    Change Advisory Board (CAB)

    The Senior Team at Cordata Healthcare Innovations currently serves as the Change Advisory Board. For normal and emergency changes, discretion is delegated to the Sr. Director of Product Engineering. The members of the Change Advisory Board provide a due diligence readiness assessment and advice about timing for any Request for Change (RFC) that are referred to it for review. This assessment should ensure that all changes to the IT environment are carefully considered to minimize the impact on users and existing services. CAB members are responsible for: * thoroughly reviewing all change requests / prioritizations * raising any potential concerns about the impact or timing of those requests\ * ensuring the changes requested * have undergone proper planning and testing * are planned to ensure the lowest possible risk to services are coordinated so changes do not impact each other * are coordinated with the campus calendar to avoid times of high impact for affected services * providing advice regarding any additional measures that should be considered prior to the change.

    Manager

    Change Management responsibilities for first level managers include the following tasks: * Review and approve timing and feasibility of RFCs * Review and approve RFCs when authorized by CA * Engage IT Communications manager to initiate communication with users * Ensure that Requestor fills out the RFC accurately and completely * Ensure staff availability to successfully complete the RFC

    Requestor

    Change Management responsibilities for the Requestor include the following tasks: * Ensure that additional resources are available in case of problems * Prepare the request for change (RFC) and submit to the appropriate Change Authority. * Incorporate feedback from the Change Authority into the RFC * Document the outcome of the change

    ClearDATA#Cordata HIPAA Compliance

    Cordata values open and honest communication which enables transparancy to all interest parties with regard to our approach to complying with HIPAA and other regulations. This site is dedicated to providing you with the details behind our policies and proceeds. Below is a high level summary of key architecture and guiding principles that maximize our security posture.

    Need Cordata Approach
    Encryption All data is encrypted in transit, end to end, and at rest. Log data is also encypted to mitigate risk of ePHI stored in log files.
    Minimum Necessary Access Access controls are always defaulted to no access unless overrided manually.
    System Access Tracking All access requests and changes of access, as well as approvals, are tracked and retained.
    PHI Segmentation All customer data is segmented. Additionally, all platform customers have unique IP spaces for additonal network segmentation.
    Monitoring All network requests, successful and unsuccessful, are logged, along with all system logs. API PHI requests (GET, POST, PUT, DELETE) log the requestor, location, and data changed/viewed. Additionally, alerts are proactively sent based on suspicious activity. OSSEC is used for IDS and file integrity monitoring.
    Auditing All log data is encrypted and unified, enabling secure access to full historical network activity records.
    Minimum Risk to Architecture Secure, encrypted access is the only form of public access enabled to servers. All API access must first pass through Cordata firewalls. To gain full access to Cordata systems, users must login via 2 factor authentication through VPN, authenticate to the specific system as a regular user, and upgrade privileges on the systems termporarily as needed.
    Vulnerability Scanning All customer and internal networks are scanned regularly for vulnerabilities.
    Intrusion Detection All production systems have intrusion detection software running to proactively detect anomalies.
    Backup All customer data is backed up every 24 hours.
    Disaster Recovery ClearDATA has an audited and regularly tested disaster recovery plan. This plan applies Cordata as a PaaS customer, and inherited from ClearDATA.
    Documentation All documentation (policies and procedures that make up our security and compliance program) is stored and versioned using Github, and published here.
    Risk Management We proactively perform risk assessments to assure changes to our infrastructure do not expose new risks to ePHI. Risks mitigation is done before changes are pushed to production.
    Workforce Training Despite not having access to the ePHI of our customers, all Cordata workforce members undergo HIPAA and security training regularly. Current training is hosted here.

    See the finer grain details of how we comply with HIPAA below. These are mapped to specific HIPAA rules. Controls marked with an (Req) are Required. Controls marked with an (A) are Addressable. In our environment, controls outlined below are implemented on all infrastructure that processes, stores, transmits or can otherwise gain access to ePHI (electronic protected health information). If have questions, please email us.

    Cordata HIPAA Business Associate Agreement (“BAA”)

    A. PURPOSE OF AGREEMENT

    Company and Agent have entered into an arrangement whereby Agent provides software services for or in conjunction with Company on behalf of certain Healthcare facilities and other healthcare providers with which Company has entered into written service agreements to provide various software and software support services. Each such facility or healthcare provider with which Company does business is a “Covered Entity” for purposes of the HIPAA (Health Insurance Portability & Accountability Act) Privacy and Security Standards. In its relationship to these Covered Entities, Company is a “Business Associate,” as that term is defined in the federal HIPAA Privacy Regulations, and Agent acts as Company’s agent or sub-contractor in carrying out certain Business Associate functions or activities for or on behalf of the Healthcare Entity. In the course of providing its services, Agent may, upon occasion, use or disclose Protected Health Information (“PHI”), provided by Company, which originated from the physician practices. This Agreement is intended to satisfy a specific requirement of the HIPAA Privacy Regulations by setting forth Agent’s responsibilities and obligations with respect to its obligations to safeguard the confidentiality and security of the PHI that it uses or accesses from Company in the performance of such services.

    B. DEFINITIONS.

    1.“Breach” (with respect to Unsecured Health Information) shall have the meaning set forth in 45 C.F.R. § 164.402, as amended from time to time, and currently means the acquisition, access, use or disclosure of protected health information in a manner not permitted under the Privacy or Security Standards and which compromises the security or privacy of the Health Information.

    2.“Business Associate” means an individual or entity that performs a function or activity on behalf of, or provides a service to a Covered Entity (as defined herein), that involves the collection, creation, use or disclosure of Health Information.

    3.“Covered Entity” means a health plan, health care clearinghouse or a health care provider who transmits any health information in electronic form in connection with a transaction covered under the HIPAA Privacy Regulations.

    4.“De-Identify” or “De-Identification” means Health Information that does not identify an individual and with respect to which there is no reasonable basis to believe that such information can be used to identify an individual.

    5.“Designated Record Set” means a group of records maintained by or for a Covered Entity comprising the enrollment, payment, claims adjudication, and case or medical management record systems maintained by or for a Covered Entity or Business Associate of the Covered Entity or used, in whole or in part, by or for the Covered Entity to make decisions about individuals. For purposes of this Section, the term “record” includes any item, collection, or grouping of information that contains Personal and Health Information and is maintained, collected, used, or disseminated by or for a Covered Entity or the Company.

    6.“Electronic Health Information” means Health Information that is transmitted or maintained in electronic media.

    7.“Electronic Media” means: (i) Electronic storage media including memory devices in computers (hard drives) and any removable/transportable d digital memory medium, such as magnetic tape or disk, optical disk, or digital memory card; or (ii) Transmission media used to exchange information already in electronic storage media. Transmission media include, for example, the internet (wide-open), extranet (using internet technology to link a business with information accessible only to collaborating parties), leased lines, dial-up lines, private networks, and the physical movement of removable/transportable electronic storage media. Certain transmissions, including of paper, via facsimile, and of voice, via telephone, are not considered to be transmissions via electronic media, because the information being exchanged did not exist in electronic form before the transmission.

    8.“Health Information” means “Protected Health Information” as this term is defined under the HIPAA Privacy Regulations, and includes any information in possession of or derived from a physician or other provider of health care or a health care service plan regarding an individual’s medical history, mental or physical condition or treatment.

    9.“Limited Data Set” means Health Information that excludes the following direct identifiers of the individuals or of relatives, employers or household members of the individual: (i) names; (ii) postal address information, other than town or city, State and zip code; (iii) telephone numbers; (iv) fax numbers; (v) electronic mail addresses; (vi) social security numbers; (vii) medical record numbers; (viii) health plan beneficiary numbers; (ix) account numbers; (x) certificate/license numbers; (xi) vehicle identifiers and serial numbers, including license plate numbers; (xii) device identifiers and serial numbers; (xii) device identifiers and serial numbers; (xiii) Web Universal Resource Locators (URLs); (xiv) Internet Protocol (IP) address numbers; (xv) biometric identifiers, including finger and voice prints; and (xvi) full face photographic images and any comparable images.

    10.“Personal and Health Information” means any individually identifiable information gathered in connection with an insurance transaction from which judgments can be made about an individual’s character, habits, avocations, finances, occupation, general reputation, credit, health or any other personal characteristics. Individually identifiable information includes the individual’s name, address, electronic mail address, telephone number, social security number and other information, alone or in combination with other publicly available information, which reveals the individual’s identity. Personal information includes the individual’s nonpublic personal financial information.

    1. “Security Standards” shall mean the Security Standards for the Protection of Electronic Health Information, 45 CFR Part 160 and Part 164, Subparts A and C.

    2. “Unsecured Health Information” shall mean unsecured PHI as set forth in 45 CFR § 164.402, as amended from time to time, and currently means Health Information that has not been rendered unusable, unreadable or indecipherable to unauthorized individuals through the use of a technology or methodology specified by the Secretary of Health and Human Services.

    C. PRIVACY OF PERSONAL AND HEALTH INFORMATION.

    1. Permitted Uses and Disclosures. Agent is permitted or required to use or disclose Health Information it collects, creates for or receives from the Company only as follows: a) Functions and Activities on the Company’s Behalf. Agent is permitted to use and disclose the minimum necessary Health Information it collects, creates for or receives from the Company in order to provide services to the Company, any Covered Entity for which the Company and/or Agent are Business Associates, or another Business Associate of such a Covered Entity. b) Agent’s Operations. Agent may use and disclose the minimum necessary Health Information or Personal and Health Information it collects, creates for or receives from the Company as necessary in order to perform Agent’s proper management and administration, or to carry out Agent’s legal responsibilities. If Agent discloses such Health Information to an agent, a subcontractor or other third party, then Agent shall obtain reasonable assurances from the agent, subcontractor or other third party to which Agent discloses such Health Information that agent, subcontractor or other third party shall: (i) hold such Health Information in confidence and use or further disclose it only for the purposes for which Agent disclosed it to the agent, subcontractor or other third party or as required by law; and (ii) notify Agent (who shall in turn promptly notify the Company) of any instances of which the agent, subcontractor or other third party becomes aware that the confidentiality of such Health Information w was breached.

    2. Prohibition on Unauthorized Use or Disclosure. Agent shall neither use nor disclose Health Information it collects, creates for or receives from the Company, except as permitted or required by this Agreement, or as permitted or required by law.

    3. Compliance with the Company’s Confidentiality/Privacy Policies. Agent shall comply with the Company’s Confidentiality, Privacy, and Security Policies that it, from time to time, may adopt as a Business Associate.

    4. De-Identification of Information/Creation of Limited Data Set. Agent shall not De-Identify Health Information it creates or receives for or from the Company, and shall not use or disclose such de-identified information, unless such de-identification is expressly permitted under the terms and conditions of this Agreement for services to be provided by Agent to the Company related to the Company’s activities for purposes of “treatment,” “payment” or “health care operations,” as those terms are defined under the HIPAA Privacy Regulations. Agent further agrees that it will not create a Limited Data Set using Health Information it creates or receives for or from the Company, nor use or disclose such Limited Data Set unless: (i) such creation, use or disclosure is expressly permitted under the terms and conditions of this Agreement; and (ii) such creation, use or disclosure is for services provided by Agent that relate to the Company’s activities for purposes of “payment” or “health care operations,” as those terms are defined under the HIPAA Privacy Regulations.

    5. Information Safeguards. Agent shall develop, implement, maintain and use appropriate administrative, technical and physical safeguards, in compliance with applicable state and federal laws, to preserve the confidentiality of and to prevent unauthorized disclosures of Health Information collected, created or received for or from the Company. Agent shall document and keep such safeguards current and, upon the Company’s reasonable request, shall provide the Company with a copy of policies and procedures related to such safeguards.

    6. Minimum Necessary. In all cases, Agent shall only use or disclose the “Minimum Necessary” amount of Health Information required for it to perform the services detailed in its Agreement with Company. “Minimum Necessary” shall have the meaning set forth for such term in the Privacy Regulations.

    D. PERSONAL AND HEALTH INFORMATION ACCESS, AMENDMENT AND DISCLOSURES.

    1. Access. Agent shall, upon the Company’s reasonable request permit and at the Company’s direction, within ten (10) business days of receipt of request, an individual (or the individual’s personal representative) to inspect and obtain copies of any Health Information about the individual which Agent collected, created or received for or from the Company and that is in Agent’s custody or control.

    2. Amendment. Agent shall, upon receipt of notice from the Company and at the Company’s direction, promptly amend or permit the Company access to amend any portion of an individual’s Health Information which Agent collected, created or received for or from the Company and that is in Agent’s custody or control.

    3. Disclosures. Agent shall document each disclosure it makes of an individual’s Health Information to a third party. Moreover, for purposes of this Section, “disclosure” includes: 1) any legal disclosure; 2) any illegal, inadvertent, wrongful, or negligent disclosure; and 3) any instance in which access was provided to an unauthorized third party to an individual’s Health Information. For the purposes of this Agreement, “legal disclosure” includes, but is not limited, any disclosures to law enforcement or other governmental authority pursuant to law and in response to a facially valid administrative or judicial order, such as a search warrant or subpoena.

    4. Disclosure Reporting. a) Legal. On the last day of each month, Agents shall forward to the Company a report of such disclosures, as required by 45 CFR §164.528; however, this requirement shall not apply If Agent has not made any such disclosures during the month. Such report shall include the applicable individual’s name, the person to whom the Health Information was disclosed, what was disclosed, why the information was disclosed, and the date of such disclosure. b) Illegal, Inadvertent or Wrongful Disclosure. Agent shall report to the Company any use or disclosure of Health Information not permitted by this Agreement or that would be in violation of the Privacy Regulations if made by Company. Business Associate shall make the report to the Company not more than twenty-four (24) hours after Agent learns of such non-permitted use or disclosure. Agent shall report such disclosure in accordance with Section D of this Agreement, even if such disclosure may not fit the definition of “Breach.” c) Termination of Agreement. Upon termination of this Agreement, Agent shall provide to the Company one final report of any and all disclosures made of all individuals’ Health Information.

    5. Inspection of Books and Records. Agent shall make its internal practices, books and records, relating to its use and disclosure of the Personal and Health Information it collects, creates or receives for or from the Company, available to the U.S. Department of Health and Human Services to determine the Company’s compliance, as a Business Associate, with the provisions of the HIPAA Privacy Regulations, whichever is applicable.

    6. Designated Record Set. Agent agrees that all Health Information received by or created for the Company shall be included in an individual’s Designated Record Set. Agent shall maintain such Designated Record Set with respect to services provided to an individual under this Agreement, and shall allow such individual to access the Designated Record Set as provided in the HIPAA Privacy Regulations.

    E. BREACH.

    1. Generally. In furtherance of Agent’s obligation under Sections D.3. and D.4 above, Agent shall report to the Company any Breach of Unsecured Health Information and any other use or disclosure of Health Information not permitted by this Agreement. Agent’s report shall contain, at a minimum, the following information, to the extent available at the time initial notice under this Section E.1 is provided, or promptly thereafter as such information becomes available: a) The nature of the Breach or non-permitted use or disclosure; b) The Health Information used or disclosed; c) The name of the person who made the Breach or non-permitted use or received the non-permitted disclosure; d) The corrective actions Agent took or shall take to prevent further Breaches or non-permitted uses or disclosures; e) The actions Agent took or shall take to mitigate any deleterious effect of the Breach or non-permitted use or disclosure; and f) Any such other information, including a written report, as the Company may reasonably request. Any report required under this Section E.1. shall be made within five (5) days of Agent becoming aware of any such Breach or other wrongful use or disclosure.

    2. Termination of Agreement. This Agreement shall terminate automatically in the event that Agent ceases performing services for or on behalf of Company or in the event that Agent otherwise ceases to be a Business Associate of either the Company or a Covered Entity with respect to whom the Company is a Business Associate. The Company may also, in addition to other available remedies, terminate this Agreement if Business Associate has materially breached any provision(s) of this Agreement and has failed to cure or take any actions to cure such material breach within five (5) calendar days of the Company informing Agent of such material breach. The Company shall exercise this right to terminate by providing Agent written notice of termination, which termination shall include the reason for the termination. Any such termination shall be effective immediately (following any applicable cure period) or at such other date specified in the Company’s notice of termination. a) Obligations upon Termination. Upon termination, cancellation, expiration or other conclusion of this Agreement or any other agreements for any reason, Agent shall comply with applicable Privacy Regulations requirements regarding the return or destruction of Health Information. b) Continuing Privacy Obligation. Agent’s obligation to protect the privacy of the Health Information be continuous and survive termination, cancellation, expiration or other conclusion of this Agreement.

    F. SECURITY OF ELECTRONIC PROTECTED HEALTH INFORMATION.

    To the extent that Agent receives, uses, creates, maintains and/or discloses any Electronic Health Information (“E-PHI”) in the course of providing services for or on behalf of Company, Agent additionally agrees: (i) to implement administrative, physical and technical Safeguards to protect the confidentiality, integrity, and availability of the E-PHI that it creates, receives, maintains, or transmits on behalf of the Company, as required by the Security Standards; (ii) to notify the Company if the Agent becomes aware of a security incident involving the Company’s E-PHI; and (iii) to ensure that any agent, including a subcontractor, to whom it provides such E-PHI agrees to implement reasonable and appropriate safeguards to protect the Company’s E-PHI.

    G. GENERAL PROVISIONS

    1. Injunctive Relief. In the event that Agent breaches any material term of this Agreement, Agent agrees that the Company has a right to obtain injunctive relief to prevent further disclosure of such Health Information. In addition to injunctive relief, the Company may also pursue any other remedy under applicable law or equity available to it.

    2. Independent Relationship. None of the provisions of this Agreement are intended to create, nor will they be deemed to create any relationship between the Parties other than that of independent parties contracting with each other as independent contractors solely for the purposes of effecting the provisions of this Agreement.

    3. Rights of Third Parties. This Agreement is between the Company and Agent and shall not be construed, interpreted, or deemed to confer any rights whatsoever to any third party or parties.

    4. Assignment. Agent may not assign its respective rights and obligations under this Agreement without the prior written consent of the Company.

    5. Indemnification and Hold Harmless. Agent shall indemnify and hold harmless the Company, and the Company’s officers, directors, employees and agents from and against any claim, cause of action, liability, damage, cost or expense, including attorneys’ fees and court or proceeding costs, arising out of or in connection with any non-permitted use or disclosure of Health Information or other breach of this Agreement by Agent or any Business Associate subcontractor, agent, representative, person or entity. This Section G.5. shall survive the termination of this Agreement.

    6. Waiver. No change, waiver or discharge of any liability or obligation hereunder on any one or more occasions shall be deemed a waiver of performance of any continuing or other obligation, or shall prohibit enforcement of any obligation on any other occasion.

    7. Assistance in Litigation or Administrative Proceedings. Agent shall make itself, and any subcontractors, employees or agents assisting Agent in the performance of its obligations under this Agreement, available to the Company, at no cost to the Company, to testify as witnesses, or otherwise, in the event of litigation or administrative proceedings being commenced against the Company, its directors, officers or employees based upon a claimed violation of any of the provisions of the Privacy Regulations or other laws relating to security and privacy, except where Agent or its subcontractor, employee or agent is a named adverse party.

    8. Expenses. Unless otherwise stated in this Agreement, each party shall bear its own costs and expenses related to compliance with the above provisions.

    9. Governing Law. The laws of the United States and the State of Ohio shall govern the interpretation, validity, performance and enforcement of this Agreement. Jurisdiction and venue for any action under this Agreement shall be in the State or Federal courts located in Hamilton County in the State of Ohio.

    10. Headings. The headings of paragraphs contained in this Agreement are for reference purposes only and shall not affect in any way the meaning or interpretation of this Agreement.

    11. Interpretation. The Parties agree that any ambiguity in this Agreement will be resolved in favor of an interpretation that protects the Health Information and facilitates Agent’s and the Company’s compliance with applicable terms and requirements of the Privacy Regulations.

    12. Entire Agreement. This Agreement constitutes the entire agreement and understanding between the Parties with respect to the subject matter of this Agreement and supersedes and replaces any and all prior written or verbal privacy agreements. If any provision of this Agreement conflicts with any of the provisions of the Privacy Regulations and other applicable law, the said Privacy Regulations or applicable law, to the extent of such conflict, shall control. The Company’s failure to insist upon or enforce strict performance of any provision of this Agreement shall not be construed as a waiver of any provision or right. Neither the course of conduct nor trade practice between the Parties shall act to modify any provision of this Agreement.

    13. Conflicts. In the event that Agent has entered into one or more agreement with the Company other than this Agreement, the terms and conditions of this Agreement shall prevail if this Agreement conflicts with any provision of any other of the Company’s agreements.

    14. Severability. In the event that any provision of this Agreement is held by a court of competent jurisdiction to be invalid or unenforceable, the remainder of the provisions of this Agreement will remain in full force and effect.

    SIGNATURE FOLLOWS

    Data Integrity Policy

    Cordata takes data integrity very seriously. As stewards and partners of Cordata 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 Cordata mission of data protection.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Data integrity Policy

    Production Systems that create, receive, store, or transmit customer data (hereafter “Production Systems”) must follow the following guidelines.

    Disabling non-essential services

    Monitoring Log-in Attempts

    Prevention of malware on Production Systems

    Patch Management

    Intrusion Detection and Vulnerability Scanning

    Production System Security

    Production Data Security

    Transmission Security

    ClearDATA# Data Management Policy

    Cordata inherits the Catalayze controls through the PaaS partnership. ClearDATA has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI). The policy and procedures will assure that complete, accurate, retrievable, and tested backups are available for all systems used by Cordata.

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

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

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Backup Policy and Procedures

    1. Perform daily snapshot backups of all systems that process, store, or transmit ePHI for Cordata Customers, including PaaS Customers that utilize the ClearDATA Backup Service
    2. Cordata Infrastructure Team, lead by the manager of infrastructure operations, is designated to be in charge of backups and leverages the ClearDATA Backup Service.
    3. Backup log stores:
      • Name of the system
      • Date & time of backup
      • Where backup stored (or to whom it was provided)
    4. Securely encrypt stored backups in a manner that protects them from loss or environmental damage.
    5. Test backups and document that files have been completely and accurately restored.

    Data Retention Policy

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

    State Medical Record Laws

    Data Retention Policy

    Disaster Recovery Policy

    Cordata inherits the ClearDATA Contingency Plan that establishes procedures to recover Cordata following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the ClearDATA Security Officer and Privacy Officer.

    The following objectives have been established for this plan:

    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 ClearDATA processing requirements during prolonged interruptions to normal operations.
    3. Identify and define the impact of interruptions to ClearDATA and Cordata systems.
    4. Assign responsibilities to designated personnel and provide guidance for recovering Cordata during prolonged periods of interruption to normal operations.
    5. Ensure coordination with other ClearDATA 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.

    This Cordata Contingency Plan has been developed as required under the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, Appendix III, November 2000, and the Health Insurance Portability and Accountability Act (HIPAA) Final Security Rule, Section §164.308(a)(7), which requires the establishment and implementation of procedures for responding to events that damage systems containing electronic protected health information.

    This Cordata Contingency Plan is created under the legislative requirements set forth in the Federal Information Security Management Act (FISMA) of 2002 and the guidelines established by the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-34, titled “Contingency Planning Guide for Information Technology Systems” dated June 2002.

    The Cordata Contingency Plan also complies with the following federal and departmental policies:

    Example of the types of disasters that would initiate this plan are natural disaster, political disturbances, man made disaster, external human threats, internal malicious activities.

    Cordata defined two categories of systems from a disaster recovery perspective.

    1. Critical Systems. These systems host application servers and database servers or are required for functioning of systems that host application servers and database servers. These systems, if unavailable, affect the integrity of data and must be restored, or have a process begun to restore them, immediately upon becoming unavailable.
    2. Non-critical Systems. These are all systems not considered critical by definition above. These systems, while they may affect the performance and overall security of critical systems, do not prevent Critical systems from functioning and being accessed appropriately. These systems are restored at a lower priority than critical systems.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Line of Succession

    The following order of succession to ensure that decision-making authority for the Cordata Contingency Plan is uninterrupted. The Chief Executive Officer, Gary Winzenread and Security Officer, Jon Stonis, are responsible for ensuring the safety of personnel and the execution of procedures documented within this Cordata Contingency Plan. If the Security Officer and CEO are unable to function as the overall authority or chooses to 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.

    Gary Winzenread gary.winzenread@cordatahealth.com 513.605.1550

    Jon Stonis jon.stonis@cordatahealth.com 513.605.1550

    Responsibilities

    The following teams have been developed and trained to respond to a contingency event affecting the IT system.

    1. The Infrastructure Team is responsible for recovery of the Cordata hosted environment, network devices, and all servers. Members of the team include personnel who are also responsible for the daily operations and maintenance of Cordata. The team leader is the Manager of Infrastructure Operations and directs the Infrastructure Team.
    2. The Engineering Team is responsible for assuring all application servers, web services, and platform add-ons are working. It is also responsible for testing redeployments and assessing damage to the environment. The team leader is the CTO and directs the Engineering Team.

    Testing and Maintenance

    The CEO and 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.

    Tabletop Testing

    Tabletop Testing is conducted in accordance with the the CMS Risk Management Handbook, Volume 2 (http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/InformationSecurity/Downloads/RMH_VII_4-5_Contingency_Plan_Exercise.pdf). The primary objective of the tabletop test is to ensure designated personnel are knowledgeable and capable of performing the notification/activation requirements and procedures as outlined in the CP, in a timely manner. The exercises include, but are not limited to:

    Technical Testing

    The primary objective of the technical test is to ensure the communication processes and data storage and recovery processes can function at an alternate site to perform the functions and capabilities of the system within the designated requirements. Technical testing shall include, but is not limited to:

    1. Notification and Activation Phase

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

    The notification sequence is listed below:

    2. Recovery Phase

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

    The following procedures are for recovering the Cordata infrastructure at the alternate site. 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 Cordata infrastructure to a production state.

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

    1. Contact Partners and Customers affected - Client Services
    2. Assess damage - Engineering
    3. Begin replication of new environment using automated and tested scripts, currently Ansible.
    4. Test new environment using pre-written tests - Engineering
    5. Test logging, security, and alerting functionality - Infrastructure
    6. Assure systems are appropriately patched and up to date. - Infrastructure
    7. Deploy environment to production - Engineering
    8. Update DNS to new environment. - Infrastructure

    ClearDATA# Disposable Media Policy

    Cordata recognizes that media containing ePHI may be reused when appropriate steps are taken to ensure that all stored ePHI has been effectively rendered inaccessible. Destruction/disposal of ePHI shall be carried out in accordance with federal and state law. The schedule for destruction/disposal shall be suspended for ePHI involved in any open investigation, audit, or litigation.

    Cordata utilizes dedicated hardware from Subcontractors. ePHI is only stored on SSD volumes in our hosted environment. All SSD volumes utilized by Cordata and ClearDATA are encrypted. Cordata does not use, own, or manage any mobile devices, SD cards, or tapes that have access to ePHI.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Disposable Media Policy

    1. All removable media is restricted, audited, and is encrypted.
    2. Cordata assumes all disposable media in its Platform may contain ePHI, so it treats all disposable media with the same protections and disposal policies.
    3. All destruction/disposal of ePHI media will be done in accordance with federal and state laws and regulations and pursuant to the Cordata’s written retention policy/schedule. Records that have satisfied the period of retention will be destroyed/disposed of in an appropriate manner.
    4. Records involved in any open investigation, audit or litigation should not be destroyed/disposed of. If notification is received that any of the above situations have occurred or there is the potential for such, the record retention schedule shall be suspended for these records until such time as the situation has been resolved. If the records have been requested in the course of a judicial or administrative hearing, a qualified protective order will be obtained to ensure that the records are returned to the organization or properly destroyed/disposed of by the requesting party.
    5. Before reuse of any media, for example all ePHI is rendered inaccessible, cleaned, or scrubbed. All media is formatted to restrict future access.
    6. All Cordata Subcontractors provide that, upon termination of the contract, they will return or destroy/dispose of all patient health information. In cases where the return or destruction/disposal is not feasible, the contract limits the use and disclosure of the information to the purposes that prevent its return or destruction/disposal.
    7. Any media containing ePHI is disposed using a method that ensures the ePHI could not be readily recovered or reconstructed.
    8. The methods of destruction, disposal, and reuse are reassessed periodically, based on current technology, accepted practices, and availability of timely and cost-effective destruction, disposal, and reuse technologies and services.
    9. In the cases of a Cordata Customer terminating a contract with Cordata and not longer utilize Cordata Services, the following actions will be taken depending on the Cordata Services in use. In all cases it is solely the responsibility of the Cordata Customer to maintain the safeguards required of HIPAA once the data is transmitted out of Cordata Systems.
      • In the case of PaaS Customer termination, ClearDATA will provide the customer with 30 days from the date of termination to export data.

    Employees Policy and Security Awareness Training

    Cordata is committed to ensuring all workforce members actively address security and compliance in their roles at Cordata. 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.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Employment Policies and Training

    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.
      • Upon completion of training, workforce members complete this form
      • Ongoing security training is conducted monthly.
      • Cordata training is hosted here and here
    2. All workforce members are granted access to formal organizational policies, which include the sanction policy for security violations.
    3. The Cordata Employee Handbook clearly states the responsibilities and acceptable behavior regarding information system usage, including rules for email, Internet, mobile devices and social media usage.
    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 Cordata 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 Cordata-purchased and -owned computers are to display this message at login and when the computer is unlocked: This computer is owned by Cordata. By logging in, unlocking, and/or using this computer you acknowledge you have seen, and follow, the use policies outlined in the Employee Handbook. Please contact us if you have problems with this - hipaa@cordatahealth.com.
    8. Access to internal Cordata systems can be requested using this form
    9. Request for modifications of access for any Cordata employee can be made using this form

    ClearDATA# Facility Access Policy

    Cordata does not physically house any systems used by its Platform in Cordata facilities. Physical security of our Platform servers is outlined here for Prominic hosted software and here for ClearDATA hosted software.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Cordata Office Policies

    1. Fire extinguishers and detectors are installed according to applicable laws and regulations.
    2. Electronic and physical media containing covered information is securely destroyed (or the information securely removed) prior to disposal.
    3. The organization securely disposes media with sensitive information.
    4. Workstation Security
      • Workstations may only be accessed and utilized by authorized workforce members to complete assigned job/contract responsibilities.
      • 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 Cordata are the property of Cordata and are distributed to users by the company.

    ClearDATA# HIPAA Mappings to Cordata Controls

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

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

    HITECH Act and Omnibus Rule: IT Security Provisions

    These were updates made to strengthen the Privacy, Security, and Breach Notifications rules within HIPAA. These updates went into effect in 2013 and were the driving force for many existing IaaS vendors to begin signing BAAs.

    Notification in the Case of Breach - 13402(a) and 13402(b)

    Cordata has a formal breach notification policy that addresses the requirements of notifying affected individuals and customers of a suspected breach of ePHI. These policies outline the relevant and responsible parties in case of a breach, forensics work to discover extent of breach, reason for breach, correction of infrastructure to prevent future breach, and requirements of notifying customers of a breach within 24 hours. Cordata is a defined Business Associate or subcontractor according to HIPAA regulations and the specific customer relationship.
    Standard Description
    In General A covered entity that accesses, maintains, retains, modifies, records, stores, destroys, or otherwise holds, uses, or discloses unsecured protected health information (as defined in subsection (h)(1)) shall, in the case of a breach of such information that is discovered by the covered entity, notify each individual whose unsecured protected health information has been, or is reasonably believed by the covered entity to have been, accessed, acquired, or disclosed as a result of such breach.
    Notification of Covered Entity by Business Associate The requirements for the HITECH Act Notification in the Case of Breach - Notification of Covered Entity by Business Associate - Uses and Disclosures: Organizational Requirements “Business Associate Contracts” standard are located in the “BA Requirements” worksheet.

    Timeliness of Notification - 13402(d)(1)

    Cordata has a breach notification policy that addresses the requirements of notifying the affected individuals or customers within 24 hours of a breach.
    Standard Description
    In General Subject to subsection (g), all notifications required under this section shall be made without unreasonable delay and in no case later than 60 calendar days after the discovery of a breach by the covered entity involved (or business associate involved in the case of a notification required under subsection (b)).

    Content of Notification - 13402(f)(1)

    Cordata has Breach Notification policies in place and they include a brief description of the breach, including the date of the breach and the date of the discovery of the breach, if known. Cordata breach notification policies include 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 PII were involved) and what the source of the breach was. Our breach notification policies include steps the individual should take to protect themselves from potential harm resulting from the breach. Our policies also provide the contact procedures for individuals to ask questions or learn additional information, which includes a toll-free telephone number, an e-mail address, Web site, or postal address.
    Standard Description
    Description of Breach Regardless of the method by which notice is provided to individuals under this section, notice of a breach shall include, to the extent possible, the following: (1) A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known.
    Description of EPHI Involved (2) 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, or disability code).
    Actions by Individuals 3) The steps individuals should take to protect themselves from potential harm resulting from the breach.
    Contact Procedures (5) Contact procedures for individuals to ask questions or learn additional information, which shall include a toll-free telephone number, an e-mail address, Web site, or postal address.

    ClearDATA# IDS Policy

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

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Intrusion Detection Policy

    ClearDATA# Incident Response Policy

    Cordata’s PaaS Provider, ClearDATA, 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:

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Incident Management Policies

    The ClearDATA incident response process follows the process recommended by SANS, an industry leader in security (www.sans.org). Process flows are a direct representation of the SANS process. Review Appendix 1 for a flowchart identifying each phase.

    Identification Phase

    1. Immediately upon observation Cordata members report suspected and known Precursors, Events, Indications, and Incidents in one of the following ways:
      1. Direct report to management, the Security Officer, Privacy Officer, or other;
      2. Email;
      3. Phone call;
      4. Online incident response form located [here]
      5. Secure Chat.
      6. Anonymously through workforce members desired channels.
      7. The individual receiving the report facilitates completion of an Incident Identification form and notifies the Security Officer (if not already done).
      8. The Security Officer determines if the issue is a Precursor, Incident, Event, or Incident.
      9. If the issue is an event, indication, or precursor the Security Officer forwards it to the appropriate resource for resolution.
        1. Non-Technical Event (minor infringement): the Security Officer completes a SIR Form (see Appendix 2) and investigates the incident.
        2. Technical Event: Assign the issue to an IT resource for resolution. This resource may also be a contractor or outsourced technical resource, in the event of a small office or lack of expertise in the area.
      10. If the issue is 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 initiation of a Security Incident Report (SIR) Form (See Appendix 2 for sample format) or an Incident Survey Form (See Appendix 4). The intent of the SIR form is to provide a summary of all events, efforts, and conclusions of each Phase of this policy and procedures.
      11. The Security Officer, Privacy Officer, or Cordata 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.
      12. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to Cordata and potentially external.

    Containment Phase (Technical)

    In this Phase, ClearDATA’s IT department attempts 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. The IT department performs 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).
      7. If it is safe, allow the system to continue to function;
        1. Complete any documentation relative to the security incident on the SIR Form.
        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

    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. Complete the Eradication Form (see Appendix 4).
    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.

    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.

    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.

    1. Responders to the security incident (SIRT Team and technical security resource) meet to review the documentation collected during the security incident.
    2. Create a “lessons learned” document and attach it to the completed SIR Form.
      1. Evaluate the cost and impact of the security incident to Cordata 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.

    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 the Cordata’s expectation for them, relative to security responsibilities. The incident response plan is tested annually.

    Security Incident Response Team (SIRT)

    Individuals needed and responsible to respond to a security incident make up a Security Incident Response Team (SIRT). Members may include the following:

    ClearDATA# 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.

    Cordata HIPAA Compliance Policies by Cordata Health Innovations LLC, are licensed under a Creative Commons License
    This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License and available on bitbucket.

    Organizational Requirements (see 164.314)

    These requirements simply outline the need for business associate agreements (BAAs) between covered entities and business associates. This requirement has recently been extended to require business associate agreements between business associates and all subcontractors. That linking, chaining together of of BAAs, has created for new and interesting legal and business questions. Basically, each layer in the chain of BAAs takes on certain responsibilities and certain risks as part of HIPAA, and there needs to be consistency. Case in point, at Cordata we have several customers that have moved over from compliant IaaS providers because those providers had breach notification timelines that were not acceptable for large healthcare enterprises. We’ve taken a proactive approach to BAAs to mitigate risk for our customers and assure consistency along the chain of BAAs.

    Business Associate Contracts or Other Arrangements - 164.314(a)(1)(i)

    Cordata has a formalized policy and process is in place concerning BAA's. BAA templates are in place and BA contracts are reviewed for consistency. All paying customers on Cordata have BAAs in place. Cordata has a formal policy and process in place for performing due diligence with any third party or vendor before engaging them. A BAA decision tree is reviewed for each third party that Cordata may partner with to ensure a BAA is executed when required.  Additionally, contracts are retained that detail the responsibility of safeguarding any information to which the provider may have access, as well as creating consistency for Cordata and Cordata customers.
    Standard Description
    Business Associate Contracts (Req) The Implementation Specifications for the HIPAA Security Rule Organizational Requirements “Business Associate Contracts or Other Arrangements” standard were evaluated under section 164.308(b)(1) above.
    Other Arrangements (Req) Rules to engaging with additional 3rd parties, like subcontractors.

    Physical Safeguards (see 164.310)

    This one is pretty straight forward - physical measures, policies, and procedures to protect a covered entity’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion. Data center security is typically easier to address than office security, though at Cordata we address both.

    Facility Access Controls - 164.310(a)(1)

    Cordata, Inc. infrastructure supporting the its environment is hosted at Rackspace, which provides hosting and recovery services for the infrastructure.

Cordata headquarters also has any written policies and procedures for safeguarding the corporate location, which includes workstations with access to the environment, from unauthorized physical access. Locks are used to prevent unauthorized access and all visitors are logged and escorted.

The Cordata environment is entirely hosted and built on hardware components provided by Rackspace, which Cordata would never have access into.
    Standard Description
    Contingency Operations (A) Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency.
    Facility Security Plan (A) Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft.
    Access Control and Validation Procedures (A) Implement procedures to control and validate a person’s access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision.
    Maintenance Records (A) Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (for example, hardware, walls, doors, and locks).

    Workstation Use - 164.310(b)

    Cordata, Inc. has policies in place that define the acceptable uses in place for workstations within the environment. These policies define the acceptable and unauthorized uses of personnel that provided workstations with access to systems potentially interacting with ePHI. These policies are enforced on all workstations. All internal email uses HIPAA-compliant vendors.
    Standard Description
    Workstation Use (Req) Implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access ePHI.

    Workstation Security - 164.310c

    Cordata has a formal Workstation and Portable Media Security Policy that identifies the specific requirements of each device. The policies define the requirements for using and/or restricted specific actions while engaged with any ePHI. Additionally, workstations are secured appropriately to limit exposure to breaches. Firewalls and hard disk encryption are used on all workstations. Actions and events are monitored and controlled, with user restrictions on downloading or copying any ePHI without documented approval and business justification. Additionally, all file storage internally at Cordata utilizes HIPAA-compliant cloud-based vendors (Google Apps and Hightail).
    Standard Description
    Workstation Security (Req) Implement physical safeguards for all workstations that access ePHI, to restrict access to authorized users.

    Device and Media Controls - 164.310(d)(1)

    Cordata has polcies and procedures for all workstations that interact with and may potentially become exposed to ePHI. These policies have requirements for secure media disposal so that ePHI cannot be recovered from these systems.

Cordata has Media Re-use requirements for the workstations, despite the fact that these workstations do not have access to and interaction with ePHI.
    Standard Description
    Disposal (Req) Implement policies and procedures to address the final disposition of ePHI, and/or the hardware or electronic media on which it is stored.
    Media Re-use (Req) Implement procedures for removal of ePHI from electronic media before the media are made available for re-use.
    Accountability (A) Maintain a record of the movements of hardware and electronic media and any person responsible therefore.
    Data Backup and Storage (A) Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.

    Technical Safeguards (see 164.312)

    This section of HIPAA outlines the technology and the policy and procedures for its use that protect electronic protected health information and control access to it. It is important to note that these requirements are not presecriptive, and there is flexibility in implementation. The key is that measures that are reasonabale and appropriate are implemented to safegaurd ePHI.

    Access Control - 164.312(a)(1)

    All users within the Cordata environment are issued a unique user name and password. All accounts are local and unique. General/shared accounts are not in place and root access is restricted and monitored.

Cordata has procedures and a process for obtaining access to ePHI should an emergency or disaster occur.

Cordata systems settings on all of its servers have session timeout features enabled and configured to terminate sessions after a period of 30 minutes or less.

Cordata encrypts all stored data in its environment using 256-bit AES encryption. Additionally, all data in transit is encrypted end to end (more below).
    Standard Description
    Unique User Identification (Req) Assign a unique name and/or number for identifying and tracking user identity.
    Emergency Access Procedure (Req) Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
    Automatic Logoff (A) Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
    Encryption and Decryption (A) Implement a method to encrypt and decrypt electronic protected health information.

    Audit Controls - 164.312(b)

    Cordata, Inc. has policies in place addressing audit trail requirements. Systems within the its environment are logging to a centralized logging solution, Logstash, which is monitoring system level events and contains user id, timestamp, event, origination, and type of event. These logs are constantly monitored for suspicious events and alerts are generated to any type of behavior that is suspicious.
    Standard Description
    Audit Controls (Req) Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.

    Integrity - 164.312c(1)

    Cordata has employed a centralized access control system for authenticating and accessing internal systems where ePHI resides. Currently, Cordata employees access a bastion host using an SSH-2 connection to access internal systems. Accounts on the internal database are restricted to a limited number of personnel, with logging in place to track all transactions.
    Standard Description
    Mechanism to Authenticate Electronic Protected (A) Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.

    Person or Entity Authentication - 164.312(d)

    Cordata, Inc. has a formal policy that describes the process of verifying a person's identity before unlocking their account, resetting their password, and/or providing access to ePHI.
    Standard Description
    Person or Entity Authentication (Req) Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.

    Transmission Security - 164.312(e)(1)

    All data in transit with Cordata is sent over internet connections through an SSLv3/TLS1.2 encrypted mechanism. Load balancers segment the traffic and send transmissions of the data to the application servers via SSLv3 encryption. Additionally, none of the internal application servers, database servers, and log and monitoring servers are accessible via public internet. All internal servers must be accessed via bastion host which are not accessible from the internet and require an SSH connection.
    Standard Description
    Integrity Controls (A) Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection.
    Encryption (A) Implement a mechanism to encrypt ePHI in transit.

    Policies and Procedures and Documentation Requirements (see 164.316)

    Policies and Procedures - 164.316(a)

    Cordata has a formalized Policy Management program that ensures that policies are developed, implemented, and updated according to best practice and organization requirements. In the words of our auditors, this is a policy about our policies.
    Standard Description
    Policies and Procedures (Req) Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors specified in § 164.306(b)(2)(i), (ii), (iii), and (iv). This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart.

    Documentation - 164.316(b)(1)(i)

    Cordata retains the necessary policies and documentation for a minimum of 6 years. All policies and procedures are available and distributed to personnel on the company shared drive (curently Box). Cordata has an update and review process for reviewing all policies and procedures and updating them as necessary. Additionally, Cordata tracks and maintains revision history, approval signature, and timestamps to ensure policies are reviewed and updated according to organization requirements.
    Standard Description
    Time Limit (Req) Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.
    Availability (Req) Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.
    Updates (Req) Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.

    Policy Management Policy

    Cordata 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 Cordata workforce members, business associates, customers, and partners are adherent to all applicable policies. Previous versions of polices are retained to assure ease of finding policies at specific historic dates in time.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Maintenance of Policies

    1. All policies are stored and up to date to maintain Cordata compliance with HIPAA, HITRUST, NIST, and other relevant standards. Updates and version control is done similar 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 accurate and up-to-date.
    3. Edits and updates made by appropriate and authorized workforce members are done on their own versions, or branches. These changes are only merged back into final, or master, versions by the Privacy or Security Officer, similarly to a pull request. All changes are linked to workforce personnel who made them and the Officer who accepted them.
    4. All policies are made accessible to all Cordata workforce members. The current master policies are published here
      • Changes can be requested to policies using this [form]change-form-for-policy
    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, whichever is later
      1. Version history of all Cordata policies is done via Bitbucket.
      2. Backup storage of all policies is done with Google apps.
    6. The policies and information security policies are reviewed and audited annually. Issues that come up as part of this process are reviewed by Cordata management to assure all risks and potential gaps are mitigated and/or fully addressed. The policy review form can be found [here]

    Additional documentation related to maintenance of policies is outlined in the Security officers responsibilities.

    Risk Management Policy

    This policy establishes the scope, objectives, and procedures of Cordata’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.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Risk Management Policies

    1. It is the policy of Cordata 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 Cordata’s information security program.
    2. Risk analysis and risk management are recognized as important components of Cordata’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 Cordata 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 Cordata Platform.
      3. While making changes to Cordata physical equipment and facilities that introduce new, untested configurations.
      4. Cordata 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. Cordata 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 Cordata 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 Cordata’s Security Officer.
    5. All Cordata 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 according to Cordata’s policies, which is outlined in the Cordata Policy Management Policy.
    6. The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of Cordata’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.

    Risk Management Procedures

    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.

    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 Cordata Platform ePHI. Determination of appropriate controls to reduce risk is dependent upon the risk tolerance of the organization consistent with its goals and mission.

    Risk Management Schedule: The two principle 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 Cordata’s information security program:

    Process Documentation

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

    Roles Policy

    Cordata 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.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    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 Cordata Privacy Officer is Jon Stonis (jon.stonis@cordatahealth.com).

    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 Cordata.

    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 Cordata ‘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. Cordata 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 Cordata’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 Cordata’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 Cordata Customer;
      13. Users are required to understand their role in Cordata’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 “X” 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.

    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 Cordata security policies and non-compliance with the security regulations [164.308(a)(1)(ii)©], and writing, implementing, and maintaining all polices, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)].

    The current Cordata Security Officer is Jon Stonis (jon.stonis@cordatahealth.com).

    Organizational Responsibilities

    The Security Officer, in collaboration with the Privacy Officer, is responsible for facilitating the development, implementation, and oversight of all activities pertaining to Cordata’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. 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 established 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. 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 Cordata 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.

      1. Promptly, properly, and consistently investigates and addresses reported violations and takes steps to prevent recurrence.
      2. Applies consistent and appropriate sanctions against workforce members who fail to comply with the security policies and procedures of Cordata.
      3. Mitigates, to the extent practicable, any harmful effect known to Cordata of a use or disclosure of ePHI in violation of Cordata’s policies and procedures, even if effect is the result of actions of Cordata 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 Cordata 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:

      1. Latest malicious software or virus alerts;
      2. Cordata’s requirement to report unauthorized attempts to access ePHI;
      3. Changes in creating or changing passwords;
      4. Additional security-focused training is provided to all workforce members by the Security Officer. This training includes, but is not limited to:
      5. Data backup plans;
      6. System auditing procedures;
      7. Redundancy procedures;
      8. Contingency plans;
      9. Virus protection;
      10. Patch management;
      11. Media Disposal and/or Re-use;
      12. Documentation requirements.

    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 Cordata’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 Cordata’s security policies and procedures.

    Sanctions of Workforce Responsibilities

    All workforce members report non-compliance of Cordata’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 Cordata’s security policies and procedures. The Security Officer may request the assistance from others.

      1. Complete an audit trail/log to identify and verify the violation and sequence of events.
      2. Interview any individual that may be aware of or involved in the incident.
      3. All individuals are required to cooperate with the investigation process and provide factual information to those conducting the investigation.
      4. Provide individuals suspected of non-compliance of the Security rule and/or Cordata’s policies and procedures the opportunity to explain their actions.
      5. The investigators thoroughly documents the investigation as the investigation occurs.

    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.

      1. 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 Cordata.

    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 setup a team to investigate and mitigate the risk of insider malicious activity. Cordata 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.

    System Access Policy

    Access to Cordata systems and application is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, consultants, and 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:

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Access Establishment and Modification

    Workforce Clearance Procedures

    Access Authorization

    VPN Access

    Our security as a platform provider, ClearDATA, enforces a rule that production data can only be obtained by going through a HIPAA & HITRUST certified and security hardened VPN. Remote access must first be requested internally by an individual by submitting the request to the Cordata Security Officer. The request form contains information about the risks associated with potentially viewing ePHI and must be signed by both the requester, their manager and the Cordata Security Officer. Once and if approved, the request is forwarded (by the Cordata Security Officer) to the support team at ClearDATA. ClearDATA creates the VPN access and provides it encrypted to the individual to whom the request is being granted. Access is removed by auto expiration every 90 days. Re-granting access is done so by the Cordata Security Officer. The Cordata Security Team reviews all active remote access logins every 30 days.

    Person or Entity Authentication

    Unique User Identification

    Automatic Logoff

    Employee Workstation Use

    All workstations at Cordata are company owned, and area mixture of Mac And Intel laptops running both MAC and WINDOWS operating systems

    Wireless Access Use

    Employee Termination Procedures

    Paper Records

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

    Password Management

    PaaS Customer Access to Systems

    Cordata grants PaaS 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 to Cordata hosted systems.

    In the case of data migration, Cordata does, on a case by case basis, support customers in importing data. In these cases Cordata support SCP assuring all data is secured and encrypted in transit.

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

    ClearDATA# Vulnerability Scanning Policy

    Cordata is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. Cordata’s PaaS, ClearDATA utilizes Nessus Scanner from Tenable to consistently scan, identify, and address vulnerabilities on our systems. ClearDATA also utilizes OSSEC on all systems, including logs, for file integrity checking and intrusion detection.

    Applicable Standards from the HITRUST Common Security Framework

    Applicable Standards from the HIPAA Security Rule

    Vulnerability Scanning Policy

    License

    All policies are licensed under CC BY-SA 4.0.

    Policy Index